yeah, sorry. http://dl.dropbox.com/u/1118905/oauth2-authorization-code.png
2011/6/9 Eran Hammer-Lahav <e...@hueniverse.com> > The last part, refresh token, is with the authorization server, not > resource server. > > > > EHL > > > > *From:* denadai2 [mailto:denad...@gmail.com] > *Sent:* Wednesday, June 08, 2011 1:27 PM > *To:* Eran Hammer-Lahav > *Cc:* oauth@ietf.org > > *Subject:* Re: [OAUTH-WG] OAuth 2.0-16 + mactoken draft 6. I don't > undestand > > > > Perfect, thank you. I made a sequence diagram for Authorization code. I > want to explain the MINIMAL authorization requisites. > > > > http://dl.dropbox.com/u/1118905/oauth2-authorization-code.png > > I explained in red the REQUIRED TLS connections. Is that all right? > > > > Thank you > > 2011/5/22 Eran Hammer-Lahav <e...@hueniverse.com> > > > > > > *From: *denadai2 <denad...@gmail.com> > *Date: *Sun, 22 May 2011 08:27:41 -0700 > *To: *Eran Hammer-lahav <e...@hueniverse.com> > *Cc: *"oauth@ietf.org" <oauth@ietf.org> > *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 <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