From: denadai2 <[email protected]<mailto:[email protected]>>
Date: Sun, 22 May 2011 08:27:41 -0700
To: Eran Hammer-lahav <[email protected]<mailto:[email protected]>>
Cc: "[email protected]<mailto:[email protected]>"
<[email protected]<mailto:[email protected]>>
Subject: Re: [OAUTH-WG] OAuth 2.0-16 + mactoken draft 6. I don't undestand
Ok thank you. I will be more specific:
1- Client -> Authorization server. (via TLS)
I build the authorization request with response_type = "code", client_id,
redirect_uri.
2- Authorization server -> Client. (without TLS)
I grant access with an authorization code generated (for example) with
enc(client_id || redirect_uri, secret). redirect_uri
is the uri of the authorization request and secret is a diffie-hellman
secret shared with the Client in a previous step.
3- Client -> Authorization server. (without TLS)
I request the access token with grant_type = "authorization_code",
client_id, code = "[authorization code of step 2]",
redirect_uri = [redirect_uri of step 2].
The Authorization server now will check that the authorization code was
issued to that client and will verify that the uri matches the
redirection URI with: dec(authorization_code, secret).
TLS Required
4- Authorization server -> Client. (without TLS)
Authorization code will return the access_token:
access_token = "..."
token_type = "mac"
mac_key= "..."
mac_algorithm = "hmac-sha-256".
The access_token is generated with sha-256(random_string())
TLS Required
5- Client -> resource owner (without TLS)
The client request a resource with access_token obtained in step 4 and
Authorization header: MAC id="[access_token provided in step 4]"
nonce="[age]:[randomstring]"
mac=hmac-sha-256(normalized_string, [mac_key provided in step4])
The resource owner will asks to the Authorization server if the
access_token is valid (if it belongs to the client and if it
not expired, if the scope is allowed etc).
Not the resource owner, the resource server.
6- resource owner - > Client (without TLS)
It will provide the resouce requested
Resource server, not owner.
- Did I understand?
Overall yes.
- how would you generate a token?
That's outside the scope of the protocol. It can be a self encoded string, or
an identifier used to DB lookup.
- Is the id field the access_token provided in the authorization response?
Yes.
EHL
Thank you. Is very difficult to verify a protocol that has so many variants :)
2011/5/22 Eran Hammer-Lahav <[email protected]<mailto:[email protected]>>
You need to be more specific about what is confusing you. V2-16 7.1 is just an
example. For using MAC you need to refer to the MAC spec.
How you generate your access token string is an internal detail but your use of
the authorization code in the algorithm is odd, IMO.
The MAC is calculated based on the normalized string as defined in the MAC spec
(and it does not include the access token).
If you want help, you need to give a real example for the wire requests and
responses.
EHL
From: [email protected]<mailto:[email protected]>
[mailto:[email protected]<mailto:[email protected]>] On Behalf Of
denadai2
Sent: Saturday, May 21, 2011 11:16 AM
To: [email protected]<mailto:[email protected]>
Subject: [OAUTH-WG] OAuth 2.0-16 + mactoken draft 6. I don't undestand
I'm trying to formal verify the OAuth 2.0 draft 16 protocol.
I want to try OAuth 2.0 with hmac token type ().
In the "Authorization Code" mode i have the response token as this:
- access_token: [access_token]
- token_type: mac
- mac_key: buabuabua
- mac_algorithm: hmac-sha-256
The access_token is calculated with hmac(client_id || authorization_code,
secret). right?
Now there is my problem. I want to access to a resource controlled by a
resource owner. Do i need to do this
GET /resource/1 HTTP/1.1
Host: example.com<http://example.com>
Authorization: MAC id = [access_token provided in the first pass]
nonce = "274312:dj83hs92"
mac = "ASDDFGDFGDG"
with mac calculated with hmac(nonce || GET || url || host || access_token,
secret)
?
I don't undestand. There is too much confusion from this:
http://tools.ietf.org/html/draft-ietf-oauth-v2-16#section-7.1 and this
http://tools.ietf.org/html/draft-ietf-oauth-v2-http-mac-00#section-1.2
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
