You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I'm working on implementing a REST API secured by an Okta Authorization server. Although this package provides everything I need for development, I think I'll face some issues when it comes to production usage. My concerns are the following:
JWK usage: the package currently loads the JWKs via each Adaptor implementation. This is not only a duplication of concerns (both existing adaptor implementations need to implement the fetching of keys even though it is the same process), but it also make it impossible to implement a caching layer so the keys are not loaded from Okta each time a token needs to be verified: the verifier currently makes 2 calls to okta during each request, first to get the jwk url from the authorization server metadata and then to get the keys from that url.
Since Okta access tokens always contain cid claim, according to current implementation of JwtVerifier it must always be verified. My only problem with that is the verifier only supports a single client ID , which means all the consumers of my API must obtain the token using the same Okta app.
I'm wondering if I'm exaggerating these problems due to my limited experience with Okta and Oauth, or they are valid concerns?
I am happy to contribute to this package if that the following improvements should be made:
inject KeyRepository into JwtVerifier that is responsible for fetching (and caching) JWKs, instead of using Adaptor::getKeys() method.
support passing an array of client IDs to JwtVerifier so it verifies tokens issued for any of the allowed clients.
Hey guys,
I'm working on implementing a REST API secured by an Okta Authorization server. Although this package provides everything I need for development, I think I'll face some issues when it comes to production usage. My concerns are the following:
Adaptorimplementation. This is not only a duplication of concerns (both existing adaptor implementations need to implement the fetching of keys even though it is the same process), but it also make it impossible to implement a caching layer so the keys are not loaded from Okta each time a token needs to be verified: the verifier currently makes 2 calls to okta during each request, first to get the jwk url from the authorization server metadata and then to get the keys from that url.cidclaim, according to current implementation ofJwtVerifierit must always be verified. My only problem with that is the verifier only supports a single client ID , which means all the consumers of my API must obtain the token using the same Okta app.I'm wondering if I'm exaggerating these problems due to my limited experience with Okta and Oauth, or they are valid concerns?
I am happy to contribute to this package if that the following improvements should be made:
KeyRepositoryintoJwtVerifierthat is responsible for fetching (and caching) JWKs, instead of usingAdaptor::getKeys()method.JwtVerifierso it verifies tokens issued for any of the allowed clients.