-
Notifications
You must be signed in to change notification settings - Fork 70
Not compatible with authorization server #57
Comments
@DPflasterer Thank you for reporting this. In theory, this would work, but there is issues with validating the tokens against our org authorization server. There is the potential that you can get this working this way, but the intended use of the library was built around API Access Management. I am going to play around with this for a little bit and see if I can get something working for you in the organizations authorization server. in the mean time, have you tried setting your |
@bretterer Yes, I have tried that. It fails with a similar but different error. I have not had a chance to troubleshoot deeper than that.
|
I am also running into the issues outlined by @DPflasterer . @bretterer I was just curious if there are any additional steps we can take to resolve this issue? |
@bretterer any updates on this? Like to use this package with the default authorization server because we don't have a license for the API Access Management |
Currently there is no update on this. The only way for this library to function correctly is to use API Access Management. |
Thanks for the quick response, any good sources I can use like another library or something like that by any change? |
@roy-pon If you are looking for basic JWT validation, you can take a look at any of the great libraries listed at https://jwt.io/libraries?language=PHP |
@bretterer I think the very first thing on the README should state that this does not work without custom authorization servers so that people don't waste their time. |
Merged into 1.4.0 Thank you! |
Is there a reason this library is not compatible with the default authorization server?
It looks like the only difference is the "well known" address:
https://${yourOktaDomain}/.well-known/openid-configuration
vs
https://${yourOktaDomain}/oauth2/${authServerId}/.well-known/openid-configuration
Essentially, if not private it should use the
domain
and not theissuer
to get the config and everything else should work, right? This seems easily doable by adding asetPublic
flag on the JwtVerifierBuilder, or parsing theissuer
for theauthServerId
and if one isn't set fall back on the default.I see in these tickets 19 and 50 that this has been brought up before and the solution was to throw an exception instead of supporting the default authorization server.
Why?
The text was updated successfully, but these errors were encountered: