Skip to Content.
Sympa Menu

oidc-deploy - Re: OIDC claim length explosion

Subject: OIDC Deployment Working Group

List archive

Re: OIDC claim length explosion


Chronological Thread 
  • From: Nick Roy <>
  • To: Alan Crosswell <>
  • Cc: "" <>
  • Subject: Re: OIDC claim length explosion
  • Date: Mon, 15 Apr 2019 22:32:11 +0000

Ahh the old Kerberos PAC field problem with groups bites us in the modern world. Lots of people do this same thing in SAML, but end up tuning attribute policies to only release groups in defined namespaces to specific RPs.

Nick

On 10 Apr 2019, at 14:46, Alan Crosswell wrote:

I just wanted to share something that just bit us:

TL;DR - make sure your openid claims are short if they go in the id_token.

We have a claim (https://api.columbia.edu/claim/group) which is mapped from a SAML attribute which is a (space-separate string) list of "claim" group memberships (managed by Grouper). One of our users has about 2500 characters worth of these. This blew up Pingfederate because the default database schema for the claim value column is NVARCHAR(2048) -- 4096 unicode bytes. We can change the schema to a larger number but this also brings up the issue of the size of a JWT id_token if we choose to include userinfo claims inside the id_token.  We don't use offline JWT's in the Authorization header but rather opaque Access Tokens and the introspection endpoint, but if we did, then there's a potential Authorization header length problem.

PingFederate has a configuration setting to not include the userinfo, in which case the id_token doesn't have much useful information for the client:

{
  "sub": "",
  "aud": "swagger",
  "jti": "HgV0vIHfut7lABErBHCbcK",
  "iat": 1554927643,
  "exp": 1554927943,
  "acr": "urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport",
  "auth_time": 1554927641
}

vs. this with userinfo inclusion enabled:

{
  "sub": "",
  "aud": "swagger",
  "jti": "Tke8nCtl2360jKmASK4PrD",
  "iat": 1554928180,
  "exp": 1554928480,
  "https://api.columbia.edu/claim/group": "demo_api_p demo_d_demo2 demo_d_demo3 demo_d_demo1 test_test1",
  "name": "Alan Docs",
  "given_name": "Alan",
  "family_name": "Docs",
  "email": "",
  "acr": "urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport",
  "auth_time": 1554928177
}

userinfo and introspect still have the claim even when it's not included in the id_token.

I can also remove the claim entirely from userinfo and allow userinfo back into the id_token so the frontend client app can greet the user by name but no longer see what groups they are a member of.

{
  "sub": "",
  "aud": "swagger",
  "jti": "gF2n7DY4VMih7Fljpew7Mj",
  "iat": 1554928360,
  "exp": 1554928660,
  "name": "Alan Docs",
  "given_name": "Alan",
  "family_name": "Docs",
  "email": "",
  "acr": "urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport",
  "auth_time": 1554928357
}

The group claim is no longer returned by the userinfo endpoint but is available as an introspect response attribute (so my backend RS can use it -- but the frontend client can't).

Just one of those real world problems.

-- 
Alan Crosswell
Associate VP & CTO

Attachment: signature.asc
Description: OpenPGP digital signature




Archive powered by MHonArc 2.6.19.

Top of Page