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.
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
