Hi Christian,
in my opinion, the token should be digitally signed in order to detect
modifications. HMAC-SHA256 or RSA are good candidates for that. If you
really need encryption depends on your privacy and security requirements.
Typical token contents are: issuer, validity/expiration, audience (could
be scope), user id, user attributes, digital signature. If revocation is
a topic, a token id could also be required. You may take a look at
standards like SAML2 or Kerberos to get inspiration. For simple use
cases, simple web tokens
(http://groups.google.com/group/oauth-wrap-wg/files) could also be an
option.
Note: I don't think a public format is less secure than a private one if
the security is based on cryptography instead of obscurity :-)
regards,
Torsten
Am 09.06.2010 22:58, schrieb Christian Holm:
Hi
We are in the process of defining a REST interface for our
application, and are looking to use OAuth 2 as the authentication
mechanism. I have read through the latest specification, and it seems
like a perfect fit for our needs. Our main dilemma is with regard to
the format of the access token. As I understand there are basicly two
options:
* Use the token as an "artifact", ie. just a randomly generated string
which is stored centrally. When accessing a resource with the token,
the token is verified by looking it up in the central repository and
making sure the requested resource can be accessed.
* Encrypt the authentication into the token. This way the resource
server can verify the access directly from the token without checking
with the central repository. This is particularly a good idea if the
authentication servers and resource servers are hosted in different
data centers.
We would like to go with the second option, but since my cryptology
knowledge is less than could be wished, I have a had time deciding on
the format. I would assume we would have to put the user, the expiry
time and the scopes into the token (perhaps with some random letters
in between) and then encrypt that using f.ex. AES. Are there any
recommendations on the format and encryption method to use? I realize
that publicly disclosing the format could weaken it slightly, so the
recommendations will have to be fairly generic.
Thanks for the help and the excellent work on the OAuth 2.0.
Christian Holm
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
