Universal Login -> My databaser

Help
1

Hi.
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?

Thank you,
Lenny

3

Hi @lenny.breyt,

Welcome to the Community!

You will get a 400 error and an alert on the widget that says wrong username or password.

You get a token/tokens. The entire response will depend on what you requested.

Take a look at the connections tab in the dashboard, from there you can try your database connections with universal login and test things to answer simple questions like these.

Hope this helps!
Dan

4

@dan.woda ,

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?

Thanks,
Lenny

5

Hi @lenny.breyt,

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).

2 Likes
6

Thanks for chiming in @markd!

7

@dan.woda @markd

Hi,

Maybe I need to explain a little bit more. The way we are using Auth0 right now:

  1. get auth0 access token by logging in user via authentication endpoint. /oauth/ro
  2. get delegation token via auth0 endpoint /delegation
  • client_id: the public client id of the app to delegate access to (i.e. the proxy)
  1. set http Authorization header in call: Authorization: Bearer

So, now we are moving to the Universal Login. Is there a similar way to keep our APIs secure by using Reverse Proxy?

Thanks,
Lenny

8

Hi @dan.woda @markd

Here is a link, to give you more information, about the way we are doing it now:

And here is what we are trying to do (Delegation Tokens)
But there is a paragraph that says that we cannot do that:

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.

So, where do we go from there?

Thanks,
Lenny

9

Hi @lenny.breyt,

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.

1 Like
10

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.