Hi, we are implementing Okta SSO integration in our product, and we followed this guide for the token validation JWT Validation Guide | Okta Developer.
We are using https://${yourOktaOrg}/.well-known/openid-configuration to get the necessary metadata
My question is: Is this validation going to work just fine for our customers if they are using the default okta organisation authorization server ? We have tested it with dev and trial accounts (/oauth2/v1/authorize?) and it all seems to work fine on our side. We just want to make sure that our customer will not have issues with the SSO integration.
Local token validation is not supported/recommended for Access Tokens issued by the Org Authorization Server, as the only intended audience for these tokens is Okta and they should only be used as authorization for Okta’s own APIs, never your own. The content of these access tokens can change at any time.
If you are looking to secure your own API endpoints with Okta issued access tokens, ensure you are using a Custom Authorization Server to issue these tokens.
I am a bit confused on how do I select which server I use for my test accounts (how can I use the Org instead of the default).
I know that our customers don’t have the Authorization section available in their okta admin so I am assuming they are using the Org server.
If that assumption is correct, does it mean the Org server tokens don’t need to be validated? or that we need to implement a specific logic for validating those? since we do not have control over our customers Okta setup
Which server is being used is determined/decided by your application. For most open source OpenID connect libraries, this is set as the “Issuer” or “Authority” or potentially via provided the URL for the Discovery doc. You would need to ensure that your application (the one requesting the tokens) is only using the Org Authorization Server.
For what use case are you currently trying to validate these tokens and where? Is this happening client-side or server-side? If you just need to validate tokens client-side and you are only using them to manage the application session and NOT as a form of authorization, then you can still locally validate the ID tokens issued by Okta.
I’ll note that the Org Authorization Server only supports OpenID Connect or Authentication use cases and should NOT be used by an API that needs to validate (Access) tokens it receives as authorization (an OAuth use case). If this is your use case, you really should be using a Custom Authorization Server, but know that not all Okta customers will have the necessary licensing to do so.
Ok, so regarding the how server is determine if we use https://${yourOktaOrg}/oauth2/v1/authorize? URL that should point to the Org server as per my understanding, and https://${yourOktaOrg}/oauth2/default/v1/authorize? would point to the custom server “default”.
For our use case we only need the authentication/application session part, our product takes care of any authorizations logic needed.
The token validation is done server-side.
The user profile is created in our app and linked to the okta user by the ID. So only thing we need is to make sure that the token is valid token and extract the user ID from it.
As a flow, based on the user data, and domain and client id provided by the customer (from their Okta Application) in our system we construct the redirect URL to okta, where the user would login into okta which will redirect them to our app where we will take the token validate it and proceed with any other logic we need.
Yup, your understanding of the different request paths and the authorization server they relate to is correct.
And yeah, if your integration is only using these OIDC tokens for authentication/application session, you should be fine continuing to use them in this way
So only thing we need is to make sure that the token is valid token and extract the user ID from it.
In that case, what about sending the Access Token to the /userinfo endpoint? That way Okta will validate that the token is valid (has not been revoked or expired) and you can confirm the User ID based on the output (for referencem, thesub claim contains the User’s UUID within Okta).
If you just want to inspect the ID token and aren’t worried about the Access Token (which is what you would send as auth to Userinfo) having expired, you can validate it locally to avoid having to make a network request to Okta. Once validated, you can be sure that the claims within have not been modified.