The message flows within OAuth 2.0 are virtually identical to the Kerberos protocol (RFC4120 and RFC1510). There is also significant overlap in functionality (e.g. OAuth token matches the Kerberos ticket, the Refresh Token matches the TGT, etc).
Since there is a huge install-base of Kerberos out there, we want to figure out how to get the best interoperability between OAuth 2.0 and Kerberos. The scenario we think most probable is for organizations to stand-up an OAuth front-end, while retaining their Kerberos infra in the back-end. What is the process in this Working Group to suggest ideas? Should I just send to this list or write-up a draft? Thanks. /thomas/ __________________________________________ From: Dick Hardt [mailto:dick.ha...@gmail.com] Sent: Tuesday, May 25, 2010 1:53 AM To: Thomas Hardjono Cc: OAuth WG Subject: Re: [OAUTH-WG] Access token opaqueness question Not sure why you want to pull the OAuth token parameters from the Kerberos token. Are you envisioning the Protected Resource is a Kerberos Client? On Mon, May 24, 2010 at 9:31 AM, Thomas Hardjono <hardj...@mit.edu<mailto:hardj...@mit.edu>> wrote: I'm still a newbie to the OAuth and WRAP discussions, so please bear with me. In Section 2.2, draft-ietf-oauth-v2-05 states that the access token is basicaly an opaque structure to the client, but which can have some "internal structure" (having meaning to the authz server and resource server): ] Access token strings can use any internal structure agreed upon ] between the authorization server and the resource server, but their ] structure is opaque to the client. Since the access token provides ] the client access to the protected resource for the life of the ] access token (or until revoked), the authorization server should ] issue access tokens which expire within an appropriate time, usually ] much shorter than the duration of the access grant. I was wondering how true this is? I want to use a Kerberos v5 ticket as the token (base encoded). The OAuth Client need not understand this structure, but could simply pass it down to the Kerberos-client (in the OS or in the browser). Then within this token (now a Kerberos ticket), the ticket fields would contain matching entries (as far as possible) to the OAuth token parameters (eg. expires_in, token_secret, etc). For the cryptographic tokens (Section 5.3), I would then use the session-key in the ticket to compute he HMAC. Would this work? Any suggestions? /thomas/ _______________________________________________ OAuth mailing list OAuth@ietf.org<mailto:OAuth@ietf.org> https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
