Invalid access token IdP initiated SSO Auth0 (SP) Okta (IdP)

Help
, , , ,
1

A little background on my current configuration. Users of the application are authenticated through an Auth0 SPA application which has an Auth0 database connection active and uses the OpenID Connect authentication flow. Now we have a user set that needs to authenticate through a customer owned Okta (IdP) with SAML2. I have created a new Auth0 SAMLP connection configured (SP) to talk to the Okta (IdP) and linked the connection through a new Auth0 SPA application as described here. If I go through my application’s normal login flow using the Auth0 hosted login (SP) I am presented with an SSO challenge to authenticate with Okta (IdP). This flow is working as expected.

I would like to get the IdP initiated SSO flow to work as well. I followed this guide. I think I am pretty close to having it work but the access token I receive back from Okta seems to be invalid. For example the access token looks like this “G-3gMBs1kzY5Q8D0zKy06cIz7hRXfqu3” in the hash. The other issue I found through debugging the auth0-js library was it seems to be expecting an id_token which was not coming through. I was able to solve this by setting the response_type=token id_token in the IdP initiated settings on my SAMLP connection. After doing that I get a valid id_token back I can parse at jwt.io and verify its my user information. I am a little confused about what to set as the response protocol in the IdP initiated SSO settings for my connection. It seems like it should be what my application uses to authenticate to Auth0 which in my case is OpenID Connect. I have it setup this way currently. I did try setting it to SAML but having it setup that way seemed like Okta was only passing through the code exchange which I am not handling that flow.

I would like to keep my core application authenticating with Auth0 using the OpenID Connect flow, but also have the ability to add enterprise SAML2, Ping Federate, etc… connections working with Auth0 as the SP and have the ability to implement the IdP initiated flow. Honestly I am not a security expert but am currently under the impression that Auth0 would act as the universal token manager for my application across connection types. However, when I try with the IdP initiated flow maybe it doesn’t work this way.

Any help would be greatly appreciated!

2

@thlap I think I understand at least partially what you are trying to achieve, but a bit curious on a couple things.

Use Case:

It seems you are doing IdP initiated SAML inbound to Auth0 and expect Auth0 to broker out OIDC to your application is this correct?

Also, you are wondering why auth0 is only issuing a 32 character opaque string for an access_token, but you expect a JWT?

If this is the case the reason for this is Auth0 expect Audience to be sent in as part of the OIDC call. The problem is this isn’t happening, because you are doing IdP initiated. So you have two options. Either set the default audience (this is a big decision because all applications will by default issue an access token for this API) or after login immediately send the user back to /authorize?prompt=none&audience=... to get the appropriate token.

Most authorization servers have a single resource server/api so the audience is implicit. Auth0 supports multiple APIs and token issuance so we require you send the audience parameter as part of the authentication.

1 Like
3

@sgmeyer First off thanks for your response it was very helpful!

It seems you are doing IdP initiated SAML inbound to Auth0 and expect Auth0 to broker out OIDC to your application is this correct?

Yes that is correct.

Also, you are wondering why auth0 is only issuing a 32 character opaque string for an access_token, but you expect a JWT?

Also correct

I did not even think about the audience being required to get a proper JWT token from the OIDC flow. Setting the default audience globally for our account is not something I want to do. I was able to get this to work this morning by invoking the checkSession method of the auth0-js SDK when my application initializes after the IdP initiated flow. Which is nice since the checkSession doesn’t reload my app and gives me back everything a normal login response would.

Questions

I had to set __enableIdPInitiatedLogin in auth0-js webauth in order to get the IdP initiated flow to work. The docs list the following warning:

Impersonation leaves your application vulnerable to CSRF attacks, since the flag allows the bypassing of the CSRF check from the state parameter if this parameter is missing from the authorization response. By using impersonation, you acknowledge that you understand and accept these risks.

Is there a way to get the state parameter configured properly in the IdP initiated flow to prevent CSRF?

A general question for you. Our SaaS based application that will need to support an internal user store (Auth0 DB) as well as multiple enterprise connections (some IdP initiated and some from normal application login Auth0 (SP) → IdP). My current design is to have each user store has their own Auth0 application and enabled connection. My application authenticates with Auth0 through OIDC exclusively and any other enterprise connection type would broker with Auth0 (SAML2, etc…) so my application only has to deal with OIDC tokens. Now that you have pointed me in the right direction for retrieving a valid JWT token after IdP initiated flow I think the goal is achieved. In your experience is this a common design or since I am using a combination of both normal and IdP initiated flows do I need to look into supporting implicit grant and code flows? I am curious what your thoughts are or any best practices you may have.

4

@THLAP,

Which is nice since the checkSession doesn’t reload my app and gives me back everything a normal login response would.

Awesome, checkSession does the /authorize?prompt=none dance in an iframe so this is a great approach.

Is there a way to get the state parameter configured properly in the IdP initiated flow to prevent CSRF?

Unfortunately, no there isn’t. The state parameters must be generated by the client, sent to auth0 during the authentication dance, then the authorization server will return the state unchanged at the time the code or tokens are sent to the user. At this time the client will compare the state it generated to trigger the flow with the state received from auth0.

In an IdP initiated flow the client never has the chance to generate a state, store it, and use that to trigger the authentication transaction.

In your experience is this a common design or since I am using a combination of both normal and IdP initiated flows do I need to look into supporting implicit grant and code flows?

100% this is very common even the IdP initiated SSO portion is common. Most of the time it is useful to do client initiated to tighten up security, but what you are doing seems legit.

I really like using service provider initiated SSO wherever possible to mitigate the CSRF potential. That said if IdP initiated SSO is your only option then that is fine.

do I need to look into supporting implicit grant and code flows?

This decision is based upon the application type. For regular web applications (templates rendered on the server) authorization code flow is the right choice. Then for native applications (iphone android, etc) authorization code flow + pkce is the right choice, single page application or pure html/javascript applications where the front end calls an API (non-hybrid) then you should use implicit grant flow.

These grant flows are designed to optimize security for the environment in which the applications run. Each flow takes various environmental concerns in mind to best protect the users data and prevent various vulnerabilities.

5

@sgmeyer Alright well this is good hear! We have a been using the implicit grant flow for our SPA and will continue to go this route now. Thank you very much for your time and advice!

1 Like
6

hi @THLAP

I’ve been exploring the same thing too. For the first part:

Now we have a user set that needs to authenticate through a customer owned Okta (IdP) with SAML2. I have created a new Auth0 SAMLP connection configured (SP) to talk to the Okta (IdP) and linked the connection through a new Auth0 SPA application as described here . If I go through my application’s normal login flow using the Auth0 hosted login (SP) I am presented with an SSO challenge to authenticate with Okta (IdP). This flow is working as expected.

Could your users login when you have SAML connection and database connection? initially I have a database connection. When I add the SAML connecdtion to Okta, none of the user could login. I could only login when only Okta connection is enabled. Wondering if you know what the problem is.

7

Hi @Oktaviandi

Everything ended up working pretty well for me. However, my requirements were slightly different than you are describing. I landed on having one default Auth0 application/user password database for all customers without their own Idp and an application/enterprise connection for each customer that did. I want to say before I got the IdP initiated flow implemented I had multiple connections working while initially testing out Okta. I had a user/pass DB and the Okta connection wired up to one application. I had the Okta domain restriction set to a different domain than users in the user/pass connection. Upon login as soon as I hit a user with the domain pointing to Okta the login would switch and pass authentication over to Okta. I only tested this with Auth0 (SP) → Okta (IdP) flow. I never tried the IdP initiated flow with multiple connections. Hope you get it figured out.