I'm interested in the possibility of requiring clients to use cryptographic tokens.
Context: I'm writing a WordPress plugin to handle OAuth 2.0 authentication. Small one-off WordPress sites (probably on a shared host) likely cannot use SSL. Such a site would necessarily be non-compliant because "the authorization server MUST require the use of a transport-layer mechanism such as TLS/SSL (or a secure channel with equivalent protections) when sending requests to the token endpoints". I understand that bearer tokens over SSL are "the way of the future", but I don't think they're the "way of the now", and the future is a ways off for small sites. OAuth 2.0 use case for WordPress site without SSL: Mars Edit, Windows Live Writer, and other desktop blog editors. (Ignore for the moment that the APIs WordPress offers to blog editors require XML POST bodies which are unsigned by core OAuth 2.0.) Tripartite Proposal: 1. Change the above "MUST" to a "SHOULD". 2. Somewhere in section 3. Obtaining an Access Token, add <<EOP During an access token request over an insecure channel, the authorization server MAY enforce the use of cryptographic tokens by requiring the client to set the secret_type parameter. If the secret_type parameter is not set for such a request to such an authorization server, the authorization server MUST issue a 400 Bad Request response with error code "unsupported_secret_type". EOP 3. In section 5. Accessing a Protected Resource, add <<EOP During a protected resource request using a over an insecure channel, the protected resource server MAY enforce the use of cryptographic tokens. If a bearer token is sent for such a request to such a protected resource server, the protected resource server MUST issue a 400 Bad Request response with an error code "invalid_signature". EOP The wording may not be the best. The idea is that these optional requirements imposed by the authorization/protected resource server should be discoverable by the client. Requiring cryptographic tokens *isn't* necessary for a WordPress plugin, just nice. For example, sending bearer tokens in the clear is no worse than sending WordPress's default auth cookies in the clear (except that one is for API calls and one is for user-agents). Saying that token endpoints "SHOULD" use SSL vs. "MUST" use SSL (part 1 of the above), though, would allow such sites to be conditionally compliant instead of non-compliant. --mdawaffe _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
