-
-
Notifications
You must be signed in to change notification settings - Fork 392
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support Self-Issued OpenID Provider #220
Comments
There's more to it than just using the embedded JWK, i had this stashed in my local repo, see if it works for you. All it takes is for the Issuer instance issuer identifier to be the one from the spec |
Ahh yes I see the comparing the subject with the key fingerprint is a crucial thing to do as well. That looks like it would work for me, I'll double check tomorrow. |
No, just trying to keep the surface in check so that i don't have to maintain stuff that potentially no one uses. I mean in the 3+ years you're the first one bringing SIOP up. |
Makes a lot of sense. Anything I can do to reduce the burden. If I take the changes you had made and flesh out some docs and tests would you in principle be interested in adding to the library |
Aside of mentioning Self-Issued in the readme i don't think there's anything more to do. |
The problem
I am trying to use this library for my OAuth services but I would also like my clients to be able to manage their own credentials. They should be able to generate a keypair locally and use that for authentication.
This is part of the OIDC.Core
https://openid.net/specs/openid-connect-core-1_0.html#SelfIssued
Describe the solution you'd like
I would like someway to be able to identify that my client is working as self issued provider.
When a issuer is identified as self-issued the acceptable yes should be taken from the token that is passed to the callback. (under the
sub_jwk
claim). Instead of using the value ofjwks_uri
A hacked solution
Having previously set up a client and a issue as standard I can patch the keystore on the issuer to get the desired effect.
There needs to be a way to configure the application to use the keys in this way.
My suggestion would be to configure
jwks_uri
to look for asub_jwk
claim instead of fetching keysI think either of those would work. Depends on if you want the value to be a valid URL even though it will not be used as a url.
Note I would suggest configuring it this way rather than off the issuer. because for development it is useful to be able to have issuers which are tied to localhost.
The text was updated successfully, but these errors were encountered: