Subject: [OAUTH-WG] Recommended token format

From: Christian Holm <[email-masked]>
Date: Wed, 9 Jun 2010 22:58:42 +0200

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

---

From: Torsten Lodderstedt <[email-masked]>
Date: Fri, 11 Jun 2010 21:35:02 +0200

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.
> 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.
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth
>