Re: [OAUTH-WG] Variant of Web Server Flow w/o direct communication

[Evan Gilbert <[e-mail]>]

On Tue, Apr 20, 2010 at 12:57 PM, Torsten Lodderstedt <
[e-mail]> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth
>