[Openid-specs-ab] Proposal for OAuth2 clients to receive an OpenID2 identifier
Breno de Medeiros
breno at google.com
Tue Jan 10 01:15:42 UTC 2012
This proposal assumes that the identifier selection is driven by the
identity provider; OpenID2 delegation introduces not insurmountable
problems to this proposal, but would add to complexity.
1. RP would register the openid realm in combination with the
client_id for OAuth2. E.g.: RP would register https://*.example.com as
2. The RP would register at least one redirect_uri for OAuth2 that
'matches' the openid.realm. E.g.:
https://openidconnect.example.com/auth_callback would be a registered
3. The RP would replace their login mechanism from OpenID2 to
OpenIDConnect. Assuming the user chooses an OpenIDConnect provider
that supported OpenID2 for that RP, the RP will use the client_id that
registers the appropriate openid.realm and that redirects to a
4. The OP will validate the RP supplied redirect_uri and recover the
openid.realm from registration information.
5. As the response to the UserInfo call, the OP will supply both the
OAuth2 id as well as an OpenID2 identifier that would have been
6. The RP will perform discovery against the returned OpenID2
identifier and find which server (OP endpoint) it delegates to.
7. If the OP endpoint is not the same as the OAuth2 issuer, the RP
will perform simple-web-discovery against the OP endpoint to establish
if the OP designates a different OAuth2 issuer.
More information about the Openid-specs-ab