Hi,
I have been involved in establishing token-based security in a
large-scale environment with central identity management services and
various web services relying on tokens for user authentication and
authorization. We also tried to adopt OAuth 1.0a. Based on my
experiences, I want to give you some feedback to
draft-hammer-http-token-auth-01 and ask some questions.
* Generally, I highly welcome the idea to strictly distinguish token
issuance and token usage. The design decision not to use any
consumer-related data (key, secret) in the "Token" scheme is a logical
consequence. Our attempt to adopt OAuth 1.0a was hindered by the fact
that the signature calculation required the consumer secret. But in
environements with central identity management, neiter user nor consumer
credentials shall be known to the services. So the new proposal is a
step in the right direction to support such deployments.
* ยง5.1 "The token identifier can be an opaque string or use a
well-defined internal structure." Does the proposal really intend to
pass token identifiers (== handles?) only? I would expect the option to
pass complete tokens in the authorization header from client to server.
In that way, no further communication is required between server and
security systems.
* How do you envision token service discovery? IMHO, a client performing
an unauthorized resource request should be given a link to the token
service a server trusts along with the 401 response. Or shall YADIS/XRDS
be employed for that purpose and how?
* From my point of view, deployments with different token types (SAML,
Kerberos, SWT, ...) would benefit if the protocol explicitely supports
token format descriptions. In the WWW-Authenticate-Header the server
could publish the formats it supports. e.g.
HTTP/1.1 401 Unauthorized
WWW-Authenticate: Token realm="http://example.com/";,
format="saml20-base64 krb5-base64 swt"
coverage="base base+body-sha-256",
timestamp="137131190"
The client does not need (and shouldn't be) aware of the meaning of the
different formats but it could pass this information with the requests
to the service issuing the required token. The token service in turn
would denote the token format as part of the response parameter. The
client would (again uninterpreted) pass this information with the
authorized resource requests and therewith gives the receiver a hint how
to handle the token.
GET /resource/1 HTTP/1.1
Host: example.com
Authorization: Token token="h480djs93hd8",
format="swt"
coverage="base",
timestamp="137131200",
nonce="dj83hs9s",
auth="djosJKDKJSD8743243/jdk33klY="
* The protocol supports authentication of message originator, replay
detection, and message integrity protection as an alternative to
transport-layer security. But, why don't you include message encryption?
In this way, one could abandon on HTTPS even if data privacy or
confidentiality is an issue. The token secret could be employed for that
purpose. A good blueprint could be Kerberos-based message-layer security.
regards,
Torsten.
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
