[Openid-specs-ab] Feedback to implementators draft
jricher at mitre.org
Mon Apr 2 13:39:40 UTC 2012
+1 to making the Basic client use the authz code flow and moving
implicit off somewhere else. I again contend that it makes sense for
Facebook, who want to host the callback URL for you, but not for other
-1 to dropping signature check requirement -- this fits a "trust but
verify" pattern and allows for a pretty simple way to implement security
in depth, especially when coupled with the checkid endpoint.
Ambivalent on nonce -- it's simple enough to implement in a client,
though the "state" parameter almost takes care of it for you.
-1 to dropping the checkid endpoint -- unless it's in favor of a more
generic "check the token with the AS" endpoint, which is what's starting
to be talked about over in the OAuth WG.
-1 to dropping symmetric signatures. They're defined under JWS, which is
pulled in by reference, so I'm not sure I see the value in cutting out
the capability from Connect.
On 03/31/2012 04:43 PM, Torsten Lodderstedt wrote:
> Hi all,
> I want to give you some feedback regarding the implementators draft
> based on ongoing discussions at Deutsche Telekom and other operators.
> We are currently considering to use OpenID Connect for two purposes:
> 1) There is an initiative to expose our login capabilities (e.g. based
> on SIM cards) to application developers via an standardized interface.
> For the first phase, we decided to go with OpenID 2.0. For the next
> phase, we are considering to migrate to OpenID connect because of its
> superiour capabilities regarding mobile apps and its alignment with
> OAuth 2.0 (which already is the authorization protocol of choice for
> other Telco APIs).
> 2) We use OpenID 2.0 with some extensions for session management and
> token handling internally at Deutsche Telekom for our consumer
> products. Clearly, OpenID connect would be the next logical step in
> order to get rid of the propietary stuff and come up with a better
> OAuth integration.
> For both use cases, we think simplicity is, beside security, a
> critical success factor. There are a couple of aspects that currently
> prevent us from adopting OpenID connect and I want to share those with
> you along with some suggestions how to cope with them.
> 1) Client Basic Profile
> In my opinion, the basic client profile should support the
> straight-forward implementation of any kind of application. I
> currently see issues regarding web and mobile apps and would therefore
> propose the following changes:
> 1.1) Use grant type code instead of implicit grant
> I would suggest to change the Basic Client Profile to use
> authorization codes instead of the implicit grant. In my opinion, code
> has the following advantages:
> - It is simpler to implement for web applications.
> - It is better suited for mobile apps because of the support for
> refresh tokens.
> - The ability to transmit large user data chunks over a back channel
> instead of the front channel is beneficially for mobile web
> applications, which most likely run on high latency, low bandwitdh
> network connections.
> - It is more secure due to the transmission of longer-lasting
> secrets via back channels only.
> 1.2) Drop the need for signature validation in basic profile
> Because of the direct TLS-protected connection between RP and AS on
> the tokens endpoint, the RP no longer needs to validate the digital
> signature of an id token. This is because the authenticity of the
> issuer is already ensured by TLS server authentication. This would
> further simplify RP implementations and follow the OAuth 2.0 spirit to
> avoid signatures if possible. Clearly, signature validation is still
> needed for all indirect tranmissions of id tokens.
> 1.3) Drop nonce from basic profile
> I would suggest to remove nonces from the basic profile and instead
> use TLS and a single-use restriction on authorization codes to prevent
> token replay. This is inline with the defintions given in the security
> consideration section of the OAuth core spec and further simplifies
> In §10.12, it is stated that any client must prevent XSRF:
> "The client MUST implement CSRF protection for its redirection URI."
> "The client SHOULD utilize the "state" request parameter ..."
> §10.5 requires:
> "Authorization codes MUST be short lived and single use."
> and also states TLS MUST be used to protect the redirect endpoints of
> clients, which use OAuth for login functions, which clearly holds for
> OpenId Connect RPs.
> "Therefore, if the client relies on the authorization code for its own
> resource owner authentication, the client redirection endpoint MUST
> require TLS."
> 2) General proposals
> Regarding the overall specification, I would like to suggest the
> following changes:
> 2.1) removal of checkid endpoint
> As stated above, Id tokens don't need to be verified for direct
> connections. Even if the RP (or any other party) needs to validate it,
> the verification of id tokens is simple given the adoption and
> simplicity of JWT. So I don't see a need for this function.
> 2.2) removal of symmetric signatures for id tokens
> I think the spec could benefit from removing support for symmetric
> signatures and support asymmetric signatures, only. RPs (even public
> clients) could validate signatures based on the AS's public key.
> Interop would benefit because of the reduced numbers of algorithms,
> security would benefit because of the limited applicability of
> symmetric signatures (two parties only!). Moreover, dual use of client
> secrets for authentication on the AS (original use case) and
> creation/validation of digital signatures would put to an end.
> What do you think?
> best regards,
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net
More information about the Openid-specs-ab