cxf-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sergey Beryozkin <sberyoz...@gmail.com>
Subject Re: Oauth2 implicit flow question
Date Tue, 19 Nov 2013 10:18:47 GMT
Hi
On 18/11/13 23:46, wang lei wrote:
> Sergy, I needed to move the segment to the last part otherwise the entire
> query will be dropped somehow.
>
> After that change, it seems the implicit flow its working. I just need to
> work on the client part, like create a sample Andriod app with the
> registered URL scheme to extract the segment.
>
> For the authorize code flow  vs implicit flow. According to the
> recommendation from the spec, we should not be using client secret when
> dealing with native apps. That way, the code flow works not much different
> to the implicit flow. Although I do find a couple of attaches that can be
> done for the URL scheme registered.
>
Authorization code flow can support public clients (such as mobile apps) 
and in such cases it can be configured to deliver the code back to the 
user or some back channel, in the former case it can be expected the the 
authenticated user will securely enter the code into the device for it 
to exchange the code for a new access token, no client secrets are involved.

I'm not trying to actively discourage you from using the implicit flow, 
I guess that if done carefully and especially in the more closed 
environments it can be made secure, but I'm repeating what I've learned 
myself so far about the authorization code flow.

> Now I would like to try the Resource Owner flow, as there is no redirect,
> would be better user experience.  Will let you know how I go.
>
Please do
Cheers, Sergey
> Many thanks,
>
>
> On Tue, Nov 19, 2013 at 11:01 AM, Sergey Beryozkin <sberyozkin@gmail.com>wrote:
>
>> Hi
>>
>> On 18/11/13 17:34, wang lei wrote:
>>
>>> Sergey,
>>>
>>> Isn't implicit flow designed to be used by clients such as mobile apps?
>>> can
>>> you please explain a little bit more on using authorization code flow for
>>> public client? Any reason, advantages?
>>>
>>>   I've read so far the experts recommending to use the authorization code
>> flow whenever possible. The implicit flow does not get a very good 'press'
>> though, it definitely requires much more care. CXF does some extra work
>> based on the comments I've seen (example it can report back the client id
>> for the browser client to validate it is the same id), etc. Please check
>> OAuth2 archives, blogs for more steps which may have to be done to get the
>> implicit flow as secure as possible
>>
>>
>>   I have raised a bug at here regarding the implicitGrantService.
>>> https://issues.apache.org/jira/browse/CXF-5395
>>>
>>> Unless that bug is fixed, I think there is no way to get implicit flow to
>>> work.
>>>
>>>   I think it is not exactly the case. The encoding issue there is real but
>> the easy workaround exists, the service also correctly reports the
>> parameters, and I've just reordered them a bit to make it simpler for the
>> code expecting the parameters stay in the same order as in the spec example
>> to parse them
>>
>> Sergey
>>
>>
>>   Cheers,
>>>
>>> Jason
>>>
>>>
>>> On Tue, Nov 19, 2013 at 1:36 AM, Sergey Beryozkin <sberyozkin@gmail.com
>>>> wrote:
>>>
>>>   Hi
>>>>
>>>> On 18/11/13 12:31, wang lei wrote:
>>>>
>>>>   thanks for the quick reply.
>>>>>
>>>>> I found the token type was set to code by the oauthClientManager. After
>>>>> changing it to token, I have managed to redirect the browser to the
>>>>> authorize.jsp. Once user allows the authorization, the form will post
to
>>>>> /decision which in turn will call the implicitGrantService.createGrant.
>>>>>
>>>>> Then I found at least 3 bugs in that service class. I will raise a jira
>>>>> ticket to cxf later.
>>>>>
>>>>> I understand that the implicit flow suggest there is no server listening
>>>>> the redirect for the client. But for mobile app it would be fb00000://
>>>>> and
>>>>> localhost for browser app. I am only using your example to demo the
>>>>> idea.
>>>>>
>>>>>
>>>>>   The mobile app is a public client but it has to be an authorization
>>>> code
>>>> flow, right ? You can use the authorization code flow for the mobile
>>>> apps,
>>>> the authorization code service can be configured to support public
>>>> clients
>>>>
>>>> Sergey
>>>>
>>>>
>>>>    Cheers
>>>>
>>>>> Jason
>>>>> On 19/11/2013 1:18 AM, "Sergey Beryozkin" <sberyozkin@gmail.com>
wrote:
>>>>>
>>>>>    Hi
>>>>>
>>>>>>
>>>>>> Thanks for trying to make it work,
>>>>>> comments below
>>>>>> On 17/11/13 11:52, wang lei wrote:
>>>>>>
>>>>>>    Hi all,
>>>>>>
>>>>>>>
>>>>>>> I am trying to design a set of server APIs to follow the oauth
>>>>>>> implicit
>>>>>>> flow. My main referring document is this one
>>>>>>> http://cxf.apache.org/docs/jax-rs-oauth2.html. I am using the
sample
>>>>>>> project at
>>>>>>> https://github.com/Talend/tesb-rt-se/tree/master/
>>>>>>> examples/cxf/jaxrs-oauth2as
>>>>>>> the starting point.
>>>>>>>
>>>>>>> It seems to me it would be a simple task to modify the sample
app to
>>>>>>> use
>>>>>>> the implicit flow instead of the authorization grant flow.
>>>>>>>
>>>>>>> I updated the socialApp.xml to use the implicitGrantService
>>>>>>>
>>>>>>>       <bean id="oauthAuthorizeService"
>>>>>>>
>>>>>>>      class="org.apache.cxf.rs.security.oauth2.services.
>>>>>>> ImplicitGrantService
>>>>>>>      ">
>>>>>>>              <property name="dataProvider" ref="oauthProvider"/>
>>>>>>>          </bean>
>>>>>>>
>>>>>>> and then the restaurantReserve.xml to use the corresponding endpoint
>>>>>>> for
>>>>>>> the new flow:
>>>>>>>
>>>>>>>        <bean id="oauthClient" class="oauth2.thirdparty.
>>>>>>> OAuthClientManager">
>>>>>>>              <!--changed to use authrorize-implicit-->
>>>>>>>              <property name="authorizationURI" value="http://localhost
>>>>>>> :
>>>>>>> ${http.port}/services/social/authorize-implicit"/>
>>>>>>>              <property name="accessTokenService"
>>>>>>> ref="atServiceClient"/>
>>>>>>>          </bean>
>>>>>>>
>>>>>>> After those changes, I expected some errors, most likely in the
client
>>>>>>> side
>>>>>>> in the restauranatReserveServiceClass. As I can see it expects
the
>>>>>>> authorize code to exchange for access toke.
>>>>>>>
>>>>>>> However, the error I got is unsupported_response_type.
>>>>>>>
>>>>>>> Sample response:
>>>>>>>
>>>>>>> Headers: {Location=[
>>>>>>> http://localhost:8080/services/reservations/reserve/
>>>>>>> complete#state=1&error=unsupported_response_type
>>>>>>> ]
>>>>>>>
>>>>>>> I debugged the code and found out that the response_type=code,
whereas
>>>>>>> the
>>>>>>> supported type is token.
>>>>>>>
>>>>>>> I then changed back to authorizationGrant, only found that the
>>>>>>> response_type is still code but the supported type matches.
>>>>>>>
>>>>>>> I understand the error -- "code" might mean the authorization
code,
>>>>>>> which
>>>>>>> is the 1st step in the authorization flow.
>>>>>>>
>>>>>>> But I have no idea how the response_type is set and by whom.
>>>>>>>
>>>>>>>     Implicit Grant Servuce returns this error because it can
not
>>>>>>> support
>>>>>>>
>>>>>>>   returning the access token as requested by the client via presenting
>>>>>> a
>>>>>> response_code 'code' which implies redirecting the user back to the
>>>>>> client
>>>>>> server: this server is not available in the implicit flow, the client
>>>>>> is
>>>>>> typically a gadget of some sort which runs directly in the end user's
>>>>>> browser
>>>>>>
>>>>>>     Any help will be appreciated. It would be idea if there is a
working
>>>>>>
>>>>>>   example for such flow.
>>>>>>>
>>>>>>>
>>>>>>>    I think it would be a good idea to expand that demo a bit
but I've
>>>>>>> no a
>>>>>>>
>>>>>> ready to show implicit code client at the moment - I know some users
>>>>>> did
>>>>>> run CXF with the implicit flow, but have no more info.
>>>>>>
>>>>>> The first step is to assume the client server is not there, please
>>>>>> check
>>>>>> Google, I'm sure there will be some examples showing a client script
>>>>>> running as an implicit code flow consumer withing a browser, I'll
work
>>>>>> at
>>>>>> some later time on improving the demo
>>>>>>
>>>>>> Thanks, Sergey
>>>>>>
>>>>>>
>>>>>>     Many thanks,
>>>>>>
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>   --
>>>>>> Sergey Beryozkin
>>>>>>
>>>>>> Talend Community Coders
>>>>>> http://coders.talend.com/
>>>>>>
>>>>>> Blog: http://sberyozkin.blogspot.com
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>> --
>>>> Sergey Beryozkin
>>>>
>>>> Talend Community Coders
>>>> http://coders.talend.com/
>>>>
>>>> Blog: http://sberyozkin.blogspot.com
>>>>
>>>>
>>>
>>
>>
>


-- 
Sergey Beryozkin

Talend Community Coders
http://coders.talend.com/

Blog: http://sberyozkin.blogspot.com

Mime
View raw message