[Openid-specs-ab] Reducing server state

John Bradley ve7jtb at ve7jtb.com
Wed Mar 6 07:46:27 UTC 2013

Connect is based on OAuth so cant change the code flow.

The implicit token id_token flow would require less state for the IdP as there is not token endpoint.  

The Authorization endpoint returns the token and id_token in the URL fragment.   That needs a bit of RP JS to extract but eliminates almost all state at the IDP other than the session state that can be managed via the normal cookie approach.    

The client redirect URI still need to be registered with the AS to prevent some serious attacks, so you are not going to be able to totally avoid keeping some client registration info unless you make the returned client_id a signed JWT with the redirect_uri in it.   I don't know if that is an especially good idea due to request size but it might work, though you need to store consent for attribute release so I don't know if the savings are worth it.

John B.

On 2013-03-06, at 3:06 PM, Frank Cornelis <info at e-contract.be> wrote:

> Hi,
> Identity Providers in general keep two types of state. One is about the different relying parties (Clients), the other is about the ongoing authentication sessions.
> 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:
> http://code.google.com/p/openid4java/issues/detail?id=193
> http://code.google.com/p/eid-idp/source/browse/trunk/eid-idp-protocol-openid/src/main/java/be/fedict/eid/idp/protocol/openid/StatelessServerAssociationStore.java
> 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 verification.
> I also had a look at OpenID Connect to see if something similar would be possible.
> 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 OpenID.
> 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 mechanism.
> 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 instances).
> Kind Regards,
> Frank.
> _______________________________________________
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-ab

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4507 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20130306/308a06b3/attachment.p7s>

More information about the Openid-specs-ab mailing list