[Openid-specs-native-apps] Consent models (re: Minutes - March 19)

Mike Varley mike.varley at securekey.com
Wed Apr 9 12:51:19 UTC 2014

I pulled this from the OAuth 2.0 Multiple Response Types spec:

(in case others haven't seen it)

When supplied as the response_type parameter in an OAuth 2.0 Authorization Request, the Authorization Server SHOULD NOT return an OAuth 2.0 Authorization Code, Access Token, Access Token Type, or ID Token in a successful response to the grant request. If a redirect_uri is supplied, the User Agent SHOULD be redirected there after granting or denying access. The request MAY include a state parameter, and if so, the Authorization Server MUST echo its value as a response parameter when issuing either a successful response or an error response. The default Response Mode for this Response Type is the query encoding. Both successful and error responses SHOULD be returned using the supplied Response Mode, or if none is supplied, using the default Response Mode.

So it is (now) clear (to me) that the state would have to be maintained by AS2 linking the consent via the SSO token and the access token grant request with the id_token.

This doesn't seem to reduce the number of round trips, however (i.e., what is the advantage of using the 'none' response_type?)


On Apr 9, 2014, at 8:34 AM, Mike Varley <mike.varley at securekey.com<mailto:mike.varley at securekey.com>> wrote:

This is what I understood the proposal to be - but I don't understand how the browser getting nothing provides the TA with any assurance it can request an AT from AS2.

If the IT was passed to AS2 during consent, then I suppose AS2 could keep some internal state as to the consent granted when an access token is requested…


On Apr 8, 2014, at 4:14 PM, Paul Madsen <paul.madsen at gmail.com<mailto:paul.madsen at gmail.com>> wrote:

for comparison, John's proposed model


On 4/8/14, 3:49 PM, John Bradley wrote:
I was thinking of using the response_type=none for the outh flow to AS2 simply to collect consent.

The JWT or SAML assertion flow would be used to get the access token from AS2.   The downside is that AS2 needs to support the assertion flow but the upside is that AS1 has the ability to revoke access without going thorough web redirects each time the AT needs to be refreshed.

On Apr 8, 2014, at 1:35 PM, Paul Madsen <paul.madsen at gmail.com<mailto:paul.madsen at gmail.com>> wrote:

I think this wsd describes John's model


Question - in the step that John refers to as 'trigger the IdP initiated login via Connect or SAML' - what support is there for an authenticated authz request?

Distinct from how the browser gets sent to AS2 is what AS2 returns - in this case a code, and the TA exchanges that code for the desired AT ( to be handed to the native app)

John was advocating a different model


On 4/8/14, 2:46 PM, John Bradley wrote:
For bootstrapping a web session in SAML as an example you could directly create a IdP initiated login URI + post body and have the browser send that to the third party AS directly.
I think that is more problematic from a security perspective as there is no way for the home AS to say compare the ip address of the browser with the ip address of the TA or make use of other authentication factors.

Logically I prefer to have the TA bootstrap the browser to itself and from there trigger the IdP initiated login via Connect or SAML.   That is the only way you can do a IdP initiated login with connect, otherwise the user needs to authenticate to there home AS in the browser somewhat defeating the point.

On Apr 8, 2014, at 12:36 PM, Paul Madsen <paul.madsen at gmail.com<mailto:paul.madsen at gmail.com>> wrote:

hi Mike, inline


On 4/7/14, 9:19 AM, Mike Varley wrote:
A couple comments/questions:
1) what is the 'API' endpoint the bootstrap URL request is going to? Is this the RS?
would be the AppInfo endpoint (hosted by AS1) that the NAPPS spec describes

To obtain application metadata information, the TA MAY make a GET or POST request to the AppInfo Endpoint.

2) Seems like a lot of round-trips. On mobile, performance will suffer
if the round trips are performed only for gathering consent ....
3) how does consent from the browser result in an AT to the App?

John proposed a model where

1) the TA is delivered an id_token targeted at AS2
2) the user agent is sent to AS2 for consent
3) once consent is obtained, the TA exchanges the id_token for an AT
4) TA hands AT to app


On Apr 4, 2014, at 5:53 PM, John Bradley <ve7jtb at ve7jtb.com<mailto:ve7jtb at ve7jtb.com>> wrote:

If the target of the SAML IdP initiated login is the OAuth authorization Uri we shouldn't need extra attributes in the SAML assertion.

Sent from my iPhone

On Apr 4, 2014, at 3:16 PM, Paul Madsen <paul.madsen at gmail.com<mailto:paul.madsen at gmail.com>> wrote:

I dont think we should preclude IdP-init SAML into the AS2 consent page - for those SaaS currently set up as SAML SPs & OAuth AS

implying us defining a scope param on the SAML Response?

On 4/4/14, 2:16 PM, John Bradley wrote:

There are two options I can think of for the last step of AS2 collecting consent.

The request can have a response_type of code and the TA gets back a code that it can use to get a AT from the AS2 token endpoint.

The other would be to make the call to AS2 with a response-type of "none" just to collect consent, getting back nothing.
The TA would then use the JWT assertion flow to exchange a JWT for the access token.

I think the second option is more secure and allows a JWT issued by AS1 to be used instead of a refresh token issued by AS2.  The advantage is that AS1 has the ability to revoke access to the resource without needing a separate API to AS2.

John B.

On Apr 4, 2014, at 2:00 PM, Paul Madsen <paul.madsen at gmail.com<mailto:paul.madsen at gmail.com>> wrote:

John, something like


On 4/4/14, 1:42 PM, John Bradley wrote:
I was thinking of a bootstrap URL that trigged idP initiated login at AS2.  That way the bootstrap URI is essentially opaque as it is both specified and consumed by the IsP/AS of the TA.

On Apr 4, 2014, at 1:26 PM, Chuck Mortimore <cmortimore at salesforce.com<mailto:cmortimore at salesforce.com>> wrote:

Sounds similar, yes, although working out a boostrap URL across different ASs might be quite difficult in practice

On Fri, Apr 4, 2014 at 10:25 AM, Paul Madsen <paul.madsen at gmail.com<mailto:paul.madsen at gmail.com>> wrote:
hey Chuck, you write

'If the TA were to simply use it's primary token to initialize an OAuth authorization request for the scope of the requesting native app, we could simplify this whole thing.  '

John had (in this thread) previously proposed something similar

'If we have a web app bootstrap AS1 could give a bootstrap URI to the App that would create a authenticated session at AS2 for the user to do the normal OAuth consent flow.'

I believe John's model accomplishes the same thing as your proposal, ie delivers the user's browser (in an authenticated state) to an AS where consent can be gathered - albeit perhaps with more steps


On 4/2/14, 5:49 PM, Chuck Mortimore wrote:
We don't think there should at all be an "implied consent" model (i.e., authentication at the AS authorizes the App for whatever it needs).    This sound quite dangerous, and don't believe this would at all be suitable for a tightly controlled enterprise environment.    We do support models that "feel" like this, but consent really isn't implicit...It's simply isn't controlled or visilbe to the the user.   We always run the request through an authorization check, and it is not at all coupled to authentication.   Picture us checking a role on the AS.

As far JIT consent model, it's a bit harder to achieve when using the Token Endpoint, unless we explicitly specify the TA is collecting consent, what to collect, etc.  Standardizing a consent UI strikes me as very difficult.

The way we've balanced the two in our environment is to always perform consent on the authorization endpoint.   Based on the configuration of the app, we're either checking server side admin defined consent, or prompting the user.

It's possible we could continue to use this model in NAPPS - if we consider the real difficult issue for users is actually authenticating, then authorization is really not a big deal.   If the TA were to simply use it's primary token to initialize an OAuth authorization request for the scope of the requesting native app, we could simplify this whole thing.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-native-apps/attachments/20140409/5bcc6d19/attachment-0001.html>

More information about the Openid-specs-native-apps mailing list