Let’s say I am using the new Universal Login, where Auth0 doing all the logging in and redirects me to a /login URL. What happens if a password is wrong? What type of error do I get back?
If the user is OK, do I get back the Auth0 ID, so I could go to my database and get all the user information?
So, I will get back one of these IDs “rs_userid”: “8397rf2f4391733e9e974c3d4d6c9b1d” and a delegation token?
Right now we are getting back a JWT token, that we send to our reverse proxy, where we use these libraries:
.NET Auth0 libraries used by the reverse proxy.
Auth0 1.11.0 Client library for the Auth0 API
Auth0-ASPNET 1.4.0 Creates an HTTP handler to accept Auth0 callback and exchange code with access token.
Are we going to be able to use these libraries with the new Universal Login or the JWT will change?
Also, does it have anything to do with the M2M login, or M2M is a different animal altogether?
I’m not sure what rs_userid is. That is not familiar to me. There are three classes of token you may encounter in the OAuth/OIDC world: ID tokens, access tokens, and refresh tokens, which are documented here.
In the OAuth/OIDC world, “JWT” is not a token type. Rather it is one way a token can be formatted. ID tokens are always formatted as JWT, while access tokens may be a JWT or may be an opaque token (just a string). If you have a token formatted as a JWT you need to look at its contents to determine what type of token it is.
M2M or the client credentials flow is an authentication / authorization flow intended to be used where machines / services are talking to each other (no human logging in).
At the moment there is no OIDC-compliant mechanism to obtain third-party API tokens. In order to facilitate a gradual migration to the new authentication pipeline, delegation can still be used to obtain third-party API tokens. This will be deprecated in future releases.
I’m afraid I don’t have much useful input here. I’ve not used delegation before. Most OAuth / OIDC providers, including Auth0, want to be able to say they are compliant with both standards, which means deprecating features like delegation and user impersonation, and stuff like using ID tokens as access tokens.
Maybe there’s a way to leverage OAuth to do what you want, since OAuth is a delegation protocol, but that’s a bit beyond my expertise.