Custom rule based on auth type?

[bingobangobongo]

I have a custom rule which is used by both api calls and standard web app calls.
I am adding additional attributes to the tokens, but how do I determine whether to add it to the idToken or the accessToken?

e.g.

context.accessToken['https://namespace'] = response;
context.idToken['https://namespace'] = response;

Can you use a switch case if statement to determine if it was an API call or a standard web app login? Or is it ok to simply add to both?

e.g.

  if(context.request.query.response_type === 'code'){
  	context.idToken['https://namespace'] = response;
  }

The docs in the following link state that I should be able to use the access token in my web app…

Authorization Code Flow

but I am also reading that web application auth should use the id token and not an access token:
" Access tokens must never be used for authentication. Access tokens cannot tell if the user has authenticated."

Tokens

This is a regular ruby on rails web app using the omniauth auth0 gem and the access token does not contain any claims when it comes back from auth0 - it just has a small string as a token.

The idToken is populated however.

Thanks

[dan.woda]

Hi @bingobangobongo,

There are a few things going on here. Lets try and clarify some things.

@bingobangobongo

but how do I determine whether to add it to the idToken or the accessToken?

ID tokens are meant to be consumed by the application requesting authentication. This would be a Web App, SPA, Mobile app etc.

Access tokens are sent by this app to an API, in order to request resources on behalf of the user. The API verifies this token and looks at the claims to determine what resources (scopes, permissions) to return.

Which token you add the claim to will be determined by which application is consuming it. Is it the resource (API), or the client (SPA, Mobile, Web App)?

An example of the claim might help narrow this down if it is still confusing.

@bingobangobongo

the access token does not contain any claims when it comes back from auth0 - it just has a small string as a token.

This is an opaque token. It is not meant to be consumed by any of your apps or APIs. It is meant only for Auth0 APIs, so you cant decode it and verify.

You must add an audience param to get an access token that is not opaque (a JWT). The audience is the custom API that is going to consume the access token.

[bingobangobongo]

Thanks - adding an audience to the params worked in retrieving the access token. This leads to 2 final questions:

1. Since my regular web app is requiring authentication, I should be using the id Token, correct? I just want to authenticate the user. I am being told that the access token should be used but this seems counter inuitive to everything i am reading.

2. If for some reason I had to use the access token as a means of authentication, by passing an audience - do this alter the user login flow i.e. does the universal login still appear?

3. A separate question regarding the user login flow. They have to click 2 buttons and it would be nice to streamline it. First they click a “Login” button on the website, this redirects to the Auth0 universal login which has another button which they click which then takes them to our Auth provider Microsoft login, where they can enter their username and password. Is there a way to bypass the universal login bit and go straight to the provider login page? [EDIT:] Took me a while but I found that if you pass a connection in the authorize params then it skips the universal login.

[dan.woda]

@bingobangobongo

I am being told that the access token should be used but this seems counter inuitive to everything i am reading.

Where are you seeing this? Your app should be using the ID token for proof of authentication.

@bingobangobongo

If for some reason I had to use the access token as a means of authentication, by passing an audience - do this alter the user login flow i.e. does the universal login still appear?

No, this doesn’t change the Universal Login flow. If you aren’t passing the token to a non-Auth0 API (one you created or otherwise), then you probably don’t need to send an audience in the request.

@bingobangobongo

Took me a while but I found that if you pass a connection in the authorize params then it skips the universal login.

Yep, that’s exactly how you do it.