On Tue, Apr 20, 2010 at 12:57 PM, Torsten Lodderstedt < [email protected]> wrote:
> Hi all, > > I would like to propose an additional variant of the Web Server Flow w/o > the need for direct communication between client and authorization server in > order to obtain authorized access/refresh tokens. Instead access and refresh > tokens should directly be send back with the redirect to the client as it is > the case in the User-Agent Flow. > Question (and sorry if I'm being dense) - what is the delta between Web Server flow + verification_code=false and User-Agent flow? > > As a major advantage the authorization server can be stateless with respect > to authorization transaction data because there is no need to hold such data > until the client obtains the tokens from the authorization server (callback, > client, verification code, identity and so on). This simplifies the > cluster/loadbalancing/fail-over architecture of the authorization server. > Moreover, the load on the authz server should be reduced and the client > saves the roundtrip time of the second call. This is even more important if > clients extensively use the new "immediate" parameter to implement a SSO > alike behavior and use this flow very often. > > The pattern proposed can be found in SAML and is very similar to the OpenId > authentication process. > > Proposal: Add an optional parameter "verification_code" to the request > (section 3.5.2.1.). > > verification_code > OPTIONAL. The parameter value must be set to "true" or "false" > (case sensitive). If set to "true" and the end user grants access, > the redirection URI includes a code the client uses to obtain > refresh and access token via a direct POST request. If set to > "false" and the end user grants access, the redirection URI includes > access and refresh token as well as the expires_in value in > query parameters. > Defaults to "true" if omitted. > > Security Considerations > > Threats: > A malicious client may pretend to be a legitimate client well-known to the > authorization server. It may attain an access token approved by the end user > and misuse it. > > Countermeasures: > I see two potential countermeasures: > a) The response is encrypted with the client_secret and thus can only be > decrypted by the legitmate client (similar to the way Kerberos handles such > things). > - The authorization process is not refused early > - requires an encrypted container as parameter > + identity theft is prevented > b) The request is signed (and thus authenticated) with an HMAC-256 based on > the client_secret. > + The inbound request can already be refused if a signature is missing or > invalid. > - token data are sent over the use agent in plaint text (which might be > acceptable since this are user data) > > Is there support for this proposal? > > regards, > Torsten. > > > > _______________________________________________ > OAuth mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/oauth >
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
