When I am fetching the /.well-known/oauth-authorization-server data from my domin I am finding that the wks_uri path is different between using my ${yourOktaDomain}/oauth2/${authorizationServerId} and /${yourOktaDomain}. The jwks_uri for the ${yourOktaDomain} gives my the key ID being used to sign my JWT tokens while the other offers two other keys that are not related or match up to the auth_token or ID_token being returned.
Is there a common strategy to use when building an API to connect to and safely forumlate the proper query based on one passed Auth Base URI?
I am using 4D which there does not seem to be a standard library that can simply be imported to make the magic happen behind the scenes.
What authorization server are you using when you request tokens? If you check the iss value in the tokens you were returned, you can verify which authorization server as used and, if you add /.well-known/oauth-authorization-server to the end of it, see its list of endpoints. You can see how to determine what your base url is for OAuth endpoints in our API docs here.
I suspect you are looking at a token that was issued by the Org Authorization Server, but are looking at the JWKS endpoint for a Custom Authorization Server. In which case, the keys will not match, as each authorization server will have its own set of keys
If I use the .authorization_endpoint from the ${yourOktaDomain}/oauth2/${authorizationServerId} I get a “The ‘OAuth2Provider._OpenBrowserForAuthorisation’ function returned an unexpected error : {“error”:“invalid_scope”,“error_description”:“One or more scopes are not configured for the authorization server resource.”}.” error message. But if I use the ${yourOktaDomain} as my auth endpoint then I am able to authenticate the user, my jwks_uri path is ${yourOktaDomain} /oauth2/v1/keys.
The challenge is that my interpritataion of the docs is that the base UIR is supposed to be ${yourOktaDomain}/oauth2/${authorizationServerId}. Or is that for a different way of doing things?
Part of my reason for hunting for the deer .well-known files was the need to try to find some items that were not part of the .well-known at the root domin. In our case the yourOktaDomain is login_lcco_co_lucas_oh_us. The digging was so that I could validate the JWT tokens being provided and passed in a Client Credentials Grant.
Are you trying to request a groups scope or one of the okta.* scopes? Both of those will only be available when using the Org Authorization Server. If you want a groups scope/claim to be returned by a custom authorization server, you will need to create your own scope/claim accordingly.
I’ll also add that it is not supported to complete local token validation (reading the claims and validing the signature without making an /introspect call to Okta) for Access Tokens issued by the Org Authorization Server as these Access Tokens are only designed to be consumed by Okta itself. More details on that found here.
Actually that may have been why I was tring to get the second set of settings. I was seeing users/groups coming over. Specifically I was tring to get to fetching users/groups like what my SAML settings. I knew that I was planning on using the /introspection for intal tests of tokens when presented. But I was looking for a more passive quicker way to do a quick check of the signing of the JWT.
Ahh, I see. If in your final integration you need to reduce any potential latency involved in making a network request to check a token’s validity, then you may want to look to use a custom authorization server (which is designed to support OAuth/authorization use cases).