I have added OIDC support to my SAP app running angular. Our REST API can validate the access token. However, our client running a production Okta tenant does not have an authorization server. Is there a URL I can use to get the metadata so I can get the JWKS URI to validate the access token? Is it more common for the app to validate the token and the RS to trust the token w/o verification?
I’m not following your question 100%.
I can comment on a few things though. Depending the type of access token you have you might be able to validate the token locally. And you could always validate it remotely. There are some trade offs when validating tokens locally, specifically related to revoked tokens (you wouldn’t be able to tell if the token or signing key have been revoked if you validate a token locally) this can be mitigated by short lived tokens. The upside of course is you save a remote http request.
The tricky thing with access tokens is that they are opaque (as defined by the OAuth2 spec), but Okta uses JWTs. Access tokens created for an issuer that looks something like this:
https://dev-123456.oktapreview.com/oauth2/default/
Could be validated locally, use the metadata endpoint to get the detail:
https://dev-123456.oktapreview.com/oauth2/default/.well-known/openid-configuration
If the issuer looks doesn’t contain /oauth2/<something> then it can ONLY be validated remotely. In this case the metadata url would be something like:
https://dev-123456.oktapreview.com/.well-known/openid-configuration
In both cases you could use the /userinfo to validate the token and retrieve the relevant user details.
Does this answer your question?
Thanks for the reply! Yes, your answer helps and partially answers my question.
My plan was to reference the .well-known/openid-configuration url to download the JSON including the JWKS_URI. Once I got a hold of the correct key I could use that to verify the signature from my .NET REST API (i.e. Resource Server).
What I’ve found is that when I was developing my solution I could use the URL: https://dev-123456.oktapreview.com/oauth2/default/.well-known/openid-configuration as you noted in your answer. But my client’s production tenant does not have the oauth2/detault. So far I’ve found I can access https://{tenant}.okta.com/.well-known/openid-configuration?client_id={clientId}. I can also access https://{tenant}.okta.com/oauth2/v1/keys?client_id={clientId}. However, the key Ids returned by that URL do not seem to match the key id found in the JWT returned after calling the authorize endpoint. Perhaps I need to add other parameters to the call to the authorize endpoint?
All that aside it looks like I’ll have to do as you suggest and remotely verify the token. Still looking for information on how I can do that from my RS.
In case of okta authorization server, we can validate the token by using JWKS. I have done it now. But I have read in okta documentation, that token from okta org auth server cacn’t be validated locally.
I didn’t get it, how it validated locally.
It was working only for id_token not for access_token.
Right, ID tokens are part of the OIDC spec. Access tokens are opaque strings in the OAuth2 spec. For “custom” authorization servers (i.e. any authorization server that is not the Okta org auth server), we support them as both opaque strings and JWTs.
For the Okta org auth server, we only support them as opaque strings, even if said string is formatted as a JWT (that ends up being an implementation detail)
I’m not sure if that helps answer your question?