search

kilork / openid

OpenID Connect Rust Library
The Unlicense
63 stars 22 forks source link

Custom claims? #2

Closed kaj closed 4 years ago

kaj commented 4 years ago

Hi! Thanks for helping making openid connect a lot less complicated with this crate!

Is there any support for custom additional claims? Or plans for such support? I didn't find anything in the docs.

kilork commented 4 years ago

Hi, glad you like it, thanks!

I have no idea about custom claims, can you give some example?

kilork commented 4 years ago

Quote from specs: https://openid.net/specs/openid-connect-core-1_0.html

5.1.2. Additional Claims While this specification defines only a small set of Claims as standard Claims, other Claims MAY be used in conjunction with the standard Claims. When using such Claims, it is RECOMMENDED that collision-resistant names be used for the Claim Names, as described in the JSON Web Token (JWT) [JWT] specification. Alternatively, Private Claim Names can be safely used when naming conflicts are unlikely to arise, as described in the JWT specification. Or, if specific additional Claims will have broad and general applicability, they can be registered with Registered Claim Names, per the JWT specification.

kaj commented 4 years ago

Yes, additional claims is what I'm talking about.

Basically, in addition to iss, sub, and the other well-known fields in struct openid::token::Claims, an identity provider / login server may include any other (site-specific) fields. The same field names will exist for all users on that IDP, and clients can be expected to know the field names statically.

I see some possible ways of handling this:

1) A field additional: BTreeMap<String, String> (or some other dictionary type) is added to openid::token::Claims and populated with any claims that don't have specific fields.

2) Structs and methods using the Claims struct is made generic on the claims type, defaulting to openid::token::Claims, so a client application can provide a local struct.

2) Very simliar to (2), the openid::token::Claims struct can have a additional: AdditionalClaims field added, where AdditionalClaims is a generic type parameter defaulting to ().

I don't know which is better. 2 and 3 would be more efficient run-time, but the cost in API complexity of adding those generics may be high.

kilork commented 4 years ago

Just took a try on second approach, @kaj can you maybe check, does this fit into your needs?