cxf-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From wang lei <jason.lei.w...@gmail.com>
Subject Re: Oauth2 implicit flow question
Date Tue, 19 Nov 2013 11:48:09 GMT
Sergey, I had a number of issues when trying to implement the resource
owner flow.
Its a very painful process. After 8 hours of hair pulling, it worked in the
end.

I will raise a few enhancement/bugs in the jira later.

One of them: https://issues.apache.org/jira/browse/CXF-5396

And two more enhancement/bugs are yet to raise. One is that no way to
report back error from a customized loginHandler.
The other one is that AccessTokenService must require a client ID, however
the Resource owner flow may not need the client id.

Many thanks,






On Tue, Nov 19, 2013 at 11:18 PM, Sergey Beryozkin <sberyozkin@gmail.com>wrote:

> 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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message