I have everything working for our iOS app - except completely unclear as to how a user native iOS login works. In speaking with support, they are telling me to use redirect (which seems ridiculous for a native app) and also the Resource Owner Password Grant for the login to the server (which seem inherently insecure). The only native login example on auth0 is a github repository with no documentation, and doesn’t go over the server interaction. I am able to retrieve a jwt token from a script I wrote, and perform login, logout, permission changes, and access the api. I am not clear from the native device how the login request works - wouldn’t the client need the secret to accomplish this login? It’s either the client goes to auth0 directly for the token, or through the server and ROPG. Is this correct? It would seem to me that the client should login to auth0 directly (hence support’s preference for redirect) but wouldn’t i build into the app some specific post request uri as opposed to a client secret that could be decompiled? What am I missing here?
Did you try the quickstart? Create the application in Auth0 as a native app, choose the iOS quickstart and you get some code and instructions.
You can do either embedded AKA ROPG or redirect. We always recommend redirect flows, but many people take on the security risks of embedded due to user experience. Both are supported by the quick start.
John
John, thanks for responding. I have a version working with iOS - the quickstart only addresses the iOS portion of it. I’m trying to figure out the concrete transactions that take place. This is what I have:
- iOS - existing user logs in with email and password.
- Email and password is sent to my server, I getToken from auth0
- I decode the jwt to get the auth0 sub
- I then look up the user id in my database, using the auth0 sub as a unique key
- I return to the user from the login request a hash with the auth0 jwt, and the id of my user in my database.
I don’t see this kind of flow indicated anywhere. At some point, every api has to crud, and the implication I’m seeing is that the object ownership should be determined by the auth0 account id, as opposed to a separate user in the my database, identified by the auth0 id.
or is there a simpler way to do this?
I’m not following very well. It sounds like your iOS app is collecting the username and password and sending them to your backend/API. Then your backend/API is using the credentials to get a token. Is this correct?
That method is not recommended. Instead, use the quickstart to do embedded (the iOS app collects the username and password and sends them directly to Auth0) or a redirect flow (the iOS app opens up the system web browser or a SafariViewController) and Auth0’s universal login page takes over.
John
Thank you for your response. I don’t want to do a redirect, I think it’s jarring to switch back and forth between apps.
The key question (flow wise) is how do i identify a user object in my database? What id or unique identifier do I use?
Your login suggestion would be fine - having iOS on a login fetch the token and then forward future requests with that token in the header. That token would contain the sub value that would be used to find the user in my system.
However, on account creation, the user would still go through my server with username and password, although the user and password wouldn’t be saved in my database. I’m assuming this would be used to indicate that the account has started, and a formal user id can be created in my database.
Or is this thought not correct?
John - In addition to my previous response, it might help to understand that we have a parallel LDAP login method. I can’t assume that all users are through auth0.
You should never pass the username and password to your backend. With embedded, it should be sent directly to Auth0. The SDK handles this for you.
Auth0 supports LDAP, so you should use Auth0 for that as well.
John
Ok - with my customers I’m not able to hand over their LDAP directories to a third party. What do you recommend here?
With AD connector:
You connect to the users’ LDAP, you do not host it yourself.
John
Hi John - it says in that article the customer needs to have a federated solution, no customers of mine really do this. That’s really useful though - I bet if i added it as an option, customers might migrate to it.
Is there any publications from auth0 about options for handling users within the app database? Is auth0 expecting every user object to have an auth0 sub, or is it when objects are created, their ownership is defined by the auth0 sub? Or something else more clever?
This topic was automatically closed 15 days after the last reply. New replies are no longer allowed.