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

Paul Madsen paul.madsen at gmail.com
Wed Apr 9 13:36:37 UTC 2014

wrt # of steps

Code flow

1) send browser to AS2
2) collect consent
3) redirect browser to TA with code
4) exchange code for AT (+RT?)

Assertion flow

1) send browser to AS2
2) collect consent
3) redirect browser to TA with nothing
4) exchange IT for AT


On 4/9/14, 9:19 AM, John Bradley wrote:
> The advantage of none is that it is more secure.
> There is no chance that code will be intercepted by another 
> application on the device.  The code response is redirected through 
> the browser.
> The code would need to be exchanged at the AS2 token endpoint for the 
> AT by the client but it typically would not be a confidential client 
> of AS2 never mind benefiting from additional security from the TA 
> having a strong relationship with AS1.
> The other problem for the code flow is that AS2 needs to provide a 
> refresh token (cutting AS1 out of the refresh flow)  or go through the 
> hole bootstrap web redirect process every time the TA needs a new AT 
> for RS2.
> Using the assertion flows the TA can be strongly authenticated by AS1 
> for each assertion, and AS1 has the ability to apply policy eg the 
> device is now in Chile but the user is logged in to a computer in 
> there office so perhaps no assertion for the TA.   If the assertion 
> for the 3rd party is granted AS2 has a fresh assertion that the AT has 
> been authenticated and authorized, then based on that plus any 
> authentication context passed in the assertion AS2, AS2 decides to 
> issue a AT for that subject based on previous consent.
> I don't think that using the assertion flow adds additional web 
> redirects for consent and it removes many steps for refresh of the AT 
> where AS1 is maintaining control of the overall security. (AS1 can 
> revoke any downstream AS )
> John B.
> On Apr 9, 2014, at 6:51 AM, Mike Varley <mike.varley at securekey.com 
> <mailto:mike.varley at securekey.com>> wrote:
>> I pulled this from the OAuth 2.0 Multiple Response Types spec:
>> (in case others haven't seen it)
>> ---
>> none
>> 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?)
>> MV
>> 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…
>>> MV
>>> 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
>>>> gACkFdmFsa 
>>>> 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
>>>>>> paul
>>>>>> 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
>>>>>>>> paul
>>>>>>>> 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
>>>>>>>>> MV
>>>>>>>>> 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:
>>>>>>>>>>>> Yes.
>>>>>>>>>>>> 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
>>>>>>>>>>>>> http://www.websequencediagrams.com/cgi-bin/cdraw?lz=cGFydGljaXBhbnQgYnJvd3NlcgoACAxUQQACDUFTMQACDlBJABEPMgoKClRBLT5BUzE6IGdldCB1c2VyIGF1dGhlbnRpY2F0ZWQKQVMxLT5UQTogUlQsQVQAKQdQSQArBUJvb3RzdHJhcChBVCkKQVBJACQGYm9vABEFVVJMAFoGAIEmBwAVBQArBgAWBQCBPQcAeQcADg4AcgUALwlyZWRpcmVjdCB0byBBUzIoaWRfdG9rZW4sc2NvcGUpAD4NMjoAgT0FenJlcXVlc3QAGhJub3RlIG92ZXIgACgFdmFsaWRhdGUgAE0ICgpBUzIAgSoLY29uc2VudCgAZgY_CgoKCgo&s=patent
>>>>>>>>>>>>> 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
>>>>>>>>>>>>>>>     paul
>>>>>>>>>>>>>>>     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.
>>>>>>>>>>>>>>>>     -cmort

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

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