panva / openid-client

OAuth 2 / OpenID Connect Client API for JavaScript Runtimes
MIT License
1.83k stars 392 forks source link

Make validateIdToken API public #262

Closed chaitankarp closed 4 years ago

chaitankarp commented 4 years ago

Hi,

Sorry if the question may seem a bit out of scope. I'm using id_token authentication flow, i use Dex for identity provider. The authentication part works great. What I'm trying to understand is how exactly do we authenticate the id_token per request? I use passport strategy.

My passport streategy looks something like this:

const issuer = new Issuer({        
    issuer: `http://${process.env['HOST_IP']}:5556/dex`,
    authorization_endpoint: `http://${process.env['HOST_IP']}:5556/dex/auth`,
    userinfo_endpoint: `http://${process.env['DEX_HOSTNAME']}:5556/dex/userinfo`,
    token_endpoint: `http://${process.env['DEX_HOSTNAME']}:5556/dex/token`,
    jwks_uri: `http://${process.env['DEX_HOSTNAME']}:5556/dex/keys`       
});

const client = new issuer.Client(config.client);
passport.serializeUser(function (user, done) {
    done(null, user);
});

passport.deserializeUser((user, done) => {
    client.userinfo(user.id_token).then((obj)=>{
        done(null, user);
    });    
});

passport.use('oidc', new Strategy({client}, (tokenSet, userinfo, done) => {
    return done(null, tokenSet);
}));

I've seen the test file client_instance.test.js making a reference to validateIdToken. But this API seem to be private. I can actually fetch the keys from jwks_uri and verify it with id_token. But i do not want to perform this since it is already being done in the library. There are also the public APIs where i find no reference to validate the id_token. Is there any other way to validate this?

The openid-configuration for dex is:

{
  "issuer": "http://192.168.1.4:5556/dex",
  "authorization_endpoint": "http://192.168.1.4:5556/dex/auth",
  "token_endpoint": "http://192.168.1.4:5556/dex/token",
  "jwks_uri": "http://192.168.1.4:5556/dex/keys",
  "userinfo_endpoint": "http://192.168.1.4:5556/dex/userinfo",
  "response_types_supported": [
    "code"
  ],
  "subject_types_supported": [
    "public"
  ],
  "id_token_signing_alg_values_supported": [
    "RS256"
  ],
  "scopes_supported": [
    "openid",
    "email",
    "groups",
    "profile",
    "offline_access"
  ],
  "token_endpoint_auth_methods_supported": [
    "client_secret_basic"
  ],
  "claims_supported": [
    "aud",
    "email",
    "email_verified",
    "exp",
    "iat",
    "iss",
    "locale",
    "name",
    "sub"
  ]
}

Thank you for this library.

panva commented 4 years ago

Question is why do you need to validate it again? What is it in the session you set that you don’t trust?

chaitankarp commented 4 years ago

I get it now. If id_token has an expiration time, shouldn't we check for that? I store the claims in the session and it has an expiry.

panva commented 4 years ago

First of all, ID Token expiry (exp) is not there to set the TTL on your own session. You're free to set a session for any amount of time fitting your use case and security considerations.

If you still want to align your RP session with the ID Token expiry, then you don't need to validate the ID Token again and again, just use your own session's expiry means.

chaitankarp commented 4 years ago

Thanks for clarifying.

panva commented 4 years ago

Please consider supporting the library if it provides value to you or your company and this and the previous support was of help to you. Supporting the library means, amongst other things, that such support will be available in the future.