[Openid-specs-ab] Reducing server state
info at e-contract.be
Wed Mar 6 06:06:08 UTC 2013
Identity Providers in general keep two types of state. One is about the
different relying parties (Clients), the other is about the ongoing
Older authentication protocols like SAML Browser POST and WS-Federation
(web passive) not really use the later one.
However, more modern authentication protocols like OpenID and OpenID
Connect keep some authentication session state.
OpenID for example uses associations, whereas OpenID Connect uses a
bunch of different tokens.
Lately I've been investigating how to reduce this type of server state.
For OpenID one can easily encode all required authentication session
state within the handle itself.
An implementation of this mechanism is given at:
Such a mechanism is interesting for large scale deployments where you
want to minimize the require state that the different (load-balanced)
identity provider instances need to share with each other.
Basically we're using AES for confidentiality and an HMAC for integrity
I also had a look at OpenID Connect to see if something similar would be
As a first step (when using Dynamic Client Registration) you can easily
encode client_secret, expires_at and registration_access_token (the bare
minimum I guess) within the client_id in a similar way as proposed for
Next comes the Browser POST towards the Authorization Endpoint. The
result of this operation is that the end-user gets authenticated. Thus
at this point the identity provider _somehow_ gets hold of all required
attributes of the end-user.
Here you would want to encode all these results within the returned code
parameter. However the Authorization Endpoint responses with a web
browser redirect. This limits the size of the code parameter. If a
browser POST would be allowed here, you could encode all attributes/data
within the code parameter. However, AFAIK, the OAuth spec does not
foresee such type of response. Can someone confirm this?
Furthermore the usage of the 'code' token has some semantics (use only
once by the Client) that is impossible to represent via the proposed
Is there any work ongoing related to the 'reduction of server state' for
large scale OpenID Connect deployments?
I want to minimize the amount of such server-side state to prevent
bottlenecks (database for sharing all the different tokens among the IdP
More information about the Openid-specs-ab