[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
paul
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
>>>>
>>>> http://www.websequencediagrams.com/cgi-bin/cdraw?lz=cGFydGljaXBhbnQgYnJvd3NlcgoACAxUQQACDU4AAQ5BUzEAAg5wcEluZm8AFQ8yAEUNUlMyCgoKVEEtPkFTMTogZ2V0IHVzZXIgYXV0aGVudGljYXRlZApBUzEtPlRBOiBSVCxBVCwgSVQALQcAXAYAMwVCb290c3RyYXAoQVQpCgB1BwAwBmJvbwAVBVVSTABmBgCBVQcAFQUALwYAFgUAgWwHAIEFBwAODgB-BQAvCXJlZGlyZWN0IHRvIEFTMihzY29wZSArIFNTTyB0b2tlbikAQQ0yOgCBTAV6cmVxdWVzdAApBisAIQxub3RlIG92ZXI!
>>>> gACkFdmFsa
>>>> WRhdGUARwoKCkFTMgCBLwtjb25zZW4ARAcpPwBfEHllcwAiEHJldHVybiBub3RoaW5nAIFjC1RBOgANCQCDBAYyOiBleGNoYW5nZSBJVAB0BlRBOiBBAIJxB04ABgZOQS0-UlMyOiBSRVNUIGNhbGwgAIJ4BQoKCgoKAAEF&s=patent
>>>>
>>>> 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
>>>>>>
>>>>>> http://www.websequencediagrams.com/cgi-bin/cdraw?lz=cGFydGljaXBhbnQgYnJvd3NlcgoACAxUQQACDU4AAQ5BUzEAAg5wcEluZm8AFQ8yAEUNUlMyCgoKVEEtPkFTMTogZ2V0IHVzZXIgYXV0aGVudGljYXRlZApBUzEtPlRBOiBSVCxBVAApBwBYBgAvBUJvb3RzdHJhcChBVCkKAHEHACwGYm9vABUFVVJMAGIGAIFRBwAVBQAvBgAWBQCBaAcAgQEHAA4OAHoFAC8JcmVkaXJlY3QgdG8gQVMyKHNjb3BlICsgU1NPIHRva2VuKQBBDTI6AIFIBXpyZXF1ZXN0ACkGKwAhDG5vdGUgb3ZlciAAKQV2YWx
>>>>>> pZGF0ZQBHCgoKQVMyAIEvC2NvbnNlbgBEByk_AF8QeWVzACIQcmV0dXJuIGNvZGUgAIFhC1RBOgAPBQCCegcyOiBleGNoYW5nZQARBgByBVRBOiBhY2Nlc3MAgQYIVEEtPk4ABhBOQS0-UlM6IFJFU1QgY2FsbCAoACoMKQoKCgoKCgABBQ&s=patent
>>>>>>
>>>>>> 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