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).
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())
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).
6- resource owner - > Client (without TLS)
It will provide the resouce requested
- Did I understand?
- how would you generate a token?
- Is the id field the access_token provided in the authorization response?
Thank you. Is very difficult to verify a protocol that has so many variants
:)
2011/5/22 Eran Hammer-Lahav <e...@hueniverse.com>
> 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:* oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] *On Behalf
> Of *denadai2
> *Sent:* Saturday, May 21, 2011 11:16 AM
> *To:* oauth@ietf.org
> *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
>
> 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
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
