Skip to content
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

Closed
1 task done
CrowdHailer opened this issue Jan 9, 2020 · 5 comments
Closed
1 task done

Support Self-Issued OpenID Provider #220

CrowdHailer opened this issue Jan 9, 2020 · 5 comments

Comments

@CrowdHailer
Copy link

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 of jwks_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.

const params = client.callbackParams(req);
  client
    .oauthCallback("https://client.example.com/callback", params, {}) // => Promise
    .then(function(tokenSet) {
      const claims = tokenSet.claims();
      issuer.keystore = function functionName() {
        return jose.JWKS.asKeyStore(
          { keys: [tokenSet.claims().sub_jwk] },
          { ignoreErrors: true }
        );
      };

      client
        .callback("https://client.example.com/callback", params, {})
        .then(function(tokenSet) {
          console.log("validated ID Token claims %j", tokenSet.claims());
        });
    });

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 a sub_jwk claim instead of fetching keys

{
  "jwks_uri": "sub_jwk",
  "jwks_uri": "https://self-issued.me"
} 

I 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.


  • i have searched the issues tracker on github for similar requests and couldn't find anything related.
@panva
Copy link
Owner

panva commented Jan 9, 2020

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 https://self-issued.me

@CrowdHailer
Copy link
Author

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.
Are their other considerations that stopped you adding it to the library

@panva
Copy link
Owner

panva commented Jan 9, 2020

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.

@CrowdHailer
Copy link
Author

don't have to maintain stuff

Makes a lot of sense.
Hopefully what I'm working on will get everyone excited and then it will be used all the time.
It really would make a huge difference to me if that part of the spec was supported in a solid OIDC library.

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

@panva
Copy link
Owner

panva commented Jan 10, 2020

Aside of mentioning Self-Issued in the readme i don't think there's anything more to do.

@panva panva closed this as completed in c5d3158 Jan 10, 2020
@github-actions github-actions bot locked and limited conversation to collaborators Apr 10, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants