You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cxf.apache.org by wang lei <ja...@gmail.com> on 2013/11/17 12:52:42 UTC
Oauth2 implicit flow question
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.
Any help will be appreciated. It would be idea if there is a working
example for such flow.
Many thanks,
Re: Oauth2 implicit flow question
Posted by Sergey Beryozkin <sb...@gmail.com>.
On 19/11/13 16:29, Sergey Beryozkin wrote:
> I've reviewed the code and I'm certain the behavior is correct with the
> respect to the owner flow client_id expectations.
>
> Basically, the spec says that if the client_id is not present then the
> runtime needs to recognize the authenticated clients which used some
> other mechanism, for example, the client may have used the client
> certificates, Kerberos or something else. The CXF does not know in such
> cases how to map an authenticated client to its Client representation
> and as such the authenticated client has to be mapped to a client id,
> example, from the filter, etc.
>
> AccessTokenService will only recognize Basic Authentication if no
> client_id is available.
>
> Ad if it is is a pubic client then of course it can not authenticate and
> as such a client_id must be available though the service needs to be
> configured to support public clients
>
> I'm still curious though what you mean with
> "One is that no way to report back error from a customized loginHandler"
>
> You can simply throw "new NotAuthorizedException" or new
> WebApplicationException(404) from it, or is it something else ?
meant 401 here
Sergey
>
> Thanks, Sergey
>
> On 19/11/13 11:58, Sergey Beryozkin wrote:
>> On 19/11/13 11:55, Sergey Beryozkin wrote:
>>> On 19/11/13 11:48, wang lei wrote:
>>>> 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 won't try to convince you otherwise, though I have my reservations,
>>> good to know you made it work 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
>>>
>>> yes, thanks, got it fixed, the typo, note it is very easy to do a
>>> resource owner flow even without the client utils, simply use WebClient
>>> directly and set few form parameters
>>>>
>>>> And two more enhancement/bugs are yet to raise. One is that no way to
>>>> report back error from a customized loginHandler.
>>> OK,
>>>> The other one is that AccessTokenService must require a client ID,
>>>> however
>>>> the Resource owner flow may not need the client id.
>>>>
>>> Hmm... Lets see
>>
>> right, we are talking about public clients then ? You will need to
>> configure AccessTokenservice to support public clients, that should help
>>
>> Sergey
>>
>>>
>>> Thanks. Sergey
>>>
>>>> Many thanks,
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> On Tue, Nov 19, 2013 at 11:18 PM, Sergey Beryozkin
>>>> <sb...@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" <sb...@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
>>>>>
>>>>
>>>
>>>
>>
>>
>
>
Re: Oauth2 implicit flow question
Posted by Sergey Beryozkin <sb...@gmail.com>.
On 20/11/13 01:34, Jason Wang wrote:
> Thanks for the clarification. I can see scope and permissions are all for
> "client" rather than "resource owners".
But if the client acts as a resource owner then RO is effectively a
client, right ?
>
> In terms of the 2 phase login, I achieved it by providing my own token and
> my own oauthRequestFilter.
Can you think of some extension point in the shipped filter ?
>
> I am trying to upgrade cxf version of an old project from 2.6.2 to the
> latest 2.7.7 but I got a few compiling errors saying
> ClientWebApplicationException and ServerWebApplicationException do not
> exist -- my code directly references them.
>
>
>
> I found that I can use 2.6.9 but not 2.7.0.
>
> So just wondering from 2.7.0, what has been changed??
>
> They existed in
> cxf-rt-frontend-jaxrs-2.6.9.jar, package org.apache.cxf.jaxrs.client.
>
They were removed, see my other response
Sergey
> Many thanks,
>
> Jason
>
>
>
>
>
>
> On Wed, Nov 20, 2013 at 11:21 AM, Sergey Beryozkin <sb...@gmail.com>wrote:
>
>> On 19/11/13 21:48, wang lei wrote:
>>
>>> Sergey, the enhancement requirement is raised here
>>> https://issues.apache.org/jira/browse/CXF-5402. I can see you already
>>> resolved it.
>>> This is the level of support you will not get from any premier service
>>> with
>>> any commercial product. Really appreciate this.
>>>
>> Thanks, nothing special really on our end, the issues have proved to be
>> very easy to solve, I'm postponing on more complex ones, and we are just
>> going a bit hyper-active as Dan is working on the releases right now.
>>
>>
>>> Yes you are right, I am using alot of my own GrantHandler, my own
>>> OauthUtils to make it work. Thats the painful part I talked about.
>>>
>>> Another question would be: (Let me know if you want me to start another
>>> thread) I need a two phase login process.
>>> The first one is about password and username validation, if passes, the
>>> Resource owner flow can grant the access token.
>>>
>>> Then I would like this token to be used to do the second phase login, for
>>> example, providing answer to a some questions.
>>> Once passed, then the token can be used to call any other services.
>>>
>>> Is there a way to achieve this with the current token structure? Is
>>> "scope"
>>> designed for this purpose?
>>>
>>>
>> Returned 'scope' is an optional hint to the client what exactly
>> Authorization Service (AS) allocated to a given access token, for example,
>> if the client requested a read and write access, and AS returned 'read'
>> only then the client can adjust its function and not to offer the users
>> write-related options, etc.
>>
>> Re a 2-phase login, is it better be done before issuing a token ? Or may
>> be you can create a custom handler which will issue yet another token after
>> the 2nd phase passes, not really sure though, as I don;t see how your whole
>> application is supposed to function (as far as the interaction with a user
>> is concerned)
>>
>> Cheers, SErgey
>>
>>
>> Many thanks,
>>>
>>>
>>>
>>> On Wed, Nov 20, 2013 at 5:29 AM, Sergey Beryozkin <sberyozkin@gmail.com
>>>> wrote:
>>>
>>> I've reviewed the code and I'm certain the behavior is correct with the
>>>> respect to the owner flow client_id expectations.
>>>>
>>>> Basically, the spec says that if the client_id is not present then the
>>>> runtime needs to recognize the authenticated clients which used some
>>>> other
>>>> mechanism, for example, the client may have used the client certificates,
>>>> Kerberos or something else. The CXF does not know in such cases how to
>>>> map
>>>> an authenticated client to its Client representation and as such the
>>>> authenticated client has to be mapped to a client id, example, from the
>>>> filter, etc.
>>>>
>>>> AccessTokenService will only recognize Basic Authentication if no
>>>> client_id is available.
>>>>
>>>> Ad if it is is a pubic client then of course it can not authenticate and
>>>> as such a client_id must be available though the service needs to be
>>>> configured to support public clients
>>>>
>>>> I'm still curious though what you mean with
>>>>
>>>> "One is that no way to report back error from a customized loginHandler"
>>>>
>>>> You can simply throw "new NotAuthorizedException" or new
>>>> WebApplicationException(404) from it, or is it something else ?
>>>>
>>>> Thanks, Sergey
>>>>
>>>>
>>>> On 19/11/13 11:58, Sergey Beryozkin wrote:
>>>>
>>>> On 19/11/13 11:55, Sergey Beryozkin wrote:
>>>>>
>>>>> On 19/11/13 11:48, wang lei wrote:
>>>>>>
>>>>>> 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 won't try to convince you otherwise, though I have my reservations,
>>>>>> good to know you made it work 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
>>>>>>>
>>>>>>>
>>>>>> yes, thanks, got it fixed, the typo, note it is very easy to do a
>>>>>> resource owner flow even without the client utils, simply use WebClient
>>>>>> directly and set few form parameters
>>>>>>
>>>>>>
>>>>>>> And two more enhancement/bugs are yet to raise. One is that no way to
>>>>>>> report back error from a customized loginHandler.
>>>>>>>
>>>>>>> OK,
>>>>>>
>>>>>> The other one is that AccessTokenService must require a client ID,
>>>>>>> however
>>>>>>> the Resource owner flow may not need the client id.
>>>>>>>
>>>>>>> Hmm... Lets see
>>>>>>>
>>>>>>
>>>>>>
>>>>> right, we are talking about public clients then ? You will need to
>>>>> configure AccessTokenservice to support public clients, that should help
>>>>>
>>>>> Sergey
>>>>>
>>>>>
>>>>> Thanks. Sergey
>>>>>>
>>>>>> Many thanks,
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Tue, Nov 19, 2013 at 11:18 PM, Sergey Beryozkin
>>>>>>> <sb...@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
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>> --
>>>> 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
>>
>
Re: Oauth2 implicit flow question
Posted by Jason Wang <ja...@gmail.com>.
Thanks for the clarification. I can see scope and permissions are all for
"client" rather than "resource owners".
In terms of the 2 phase login, I achieved it by providing my own token and
my own oauthRequestFilter.
I am trying to upgrade cxf version of an old project from 2.6.2 to the
latest 2.7.7 but I got a few compiling errors saying
ClientWebApplicationException and ServerWebApplicationException do not
exist -- my code directly references them.
I found that I can use 2.6.9 but not 2.7.0.
So just wondering from 2.7.0, what has been changed??
They existed in
cxf-rt-frontend-jaxrs-2.6.9.jar, package org.apache.cxf.jaxrs.client.
Many thanks,
Jason
On Wed, Nov 20, 2013 at 11:21 AM, Sergey Beryozkin <sb...@gmail.com>wrote:
> On 19/11/13 21:48, wang lei wrote:
>
>> Sergey, the enhancement requirement is raised here
>> https://issues.apache.org/jira/browse/CXF-5402. I can see you already
>> resolved it.
>> This is the level of support you will not get from any premier service
>> with
>> any commercial product. Really appreciate this.
>>
> Thanks, nothing special really on our end, the issues have proved to be
> very easy to solve, I'm postponing on more complex ones, and we are just
> going a bit hyper-active as Dan is working on the releases right now.
>
>
>> Yes you are right, I am using alot of my own GrantHandler, my own
>> OauthUtils to make it work. Thats the painful part I talked about.
>>
>> Another question would be: (Let me know if you want me to start another
>> thread) I need a two phase login process.
>> The first one is about password and username validation, if passes, the
>> Resource owner flow can grant the access token.
>>
>> Then I would like this token to be used to do the second phase login, for
>> example, providing answer to a some questions.
>> Once passed, then the token can be used to call any other services.
>>
>> Is there a way to achieve this with the current token structure? Is
>> "scope"
>> designed for this purpose?
>>
>>
> Returned 'scope' is an optional hint to the client what exactly
> Authorization Service (AS) allocated to a given access token, for example,
> if the client requested a read and write access, and AS returned 'read'
> only then the client can adjust its function and not to offer the users
> write-related options, etc.
>
> Re a 2-phase login, is it better be done before issuing a token ? Or may
> be you can create a custom handler which will issue yet another token after
> the 2nd phase passes, not really sure though, as I don;t see how your whole
> application is supposed to function (as far as the interaction with a user
> is concerned)
>
> Cheers, SErgey
>
>
> Many thanks,
>>
>>
>>
>> On Wed, Nov 20, 2013 at 5:29 AM, Sergey Beryozkin <sberyozkin@gmail.com
>> >wrote:
>>
>> I've reviewed the code and I'm certain the behavior is correct with the
>>> respect to the owner flow client_id expectations.
>>>
>>> Basically, the spec says that if the client_id is not present then the
>>> runtime needs to recognize the authenticated clients which used some
>>> other
>>> mechanism, for example, the client may have used the client certificates,
>>> Kerberos or something else. The CXF does not know in such cases how to
>>> map
>>> an authenticated client to its Client representation and as such the
>>> authenticated client has to be mapped to a client id, example, from the
>>> filter, etc.
>>>
>>> AccessTokenService will only recognize Basic Authentication if no
>>> client_id is available.
>>>
>>> Ad if it is is a pubic client then of course it can not authenticate and
>>> as such a client_id must be available though the service needs to be
>>> configured to support public clients
>>>
>>> I'm still curious though what you mean with
>>>
>>> "One is that no way to report back error from a customized loginHandler"
>>>
>>> You can simply throw "new NotAuthorizedException" or new
>>> WebApplicationException(404) from it, or is it something else ?
>>>
>>> Thanks, Sergey
>>>
>>>
>>> On 19/11/13 11:58, Sergey Beryozkin wrote:
>>>
>>> On 19/11/13 11:55, Sergey Beryozkin wrote:
>>>>
>>>> On 19/11/13 11:48, wang lei wrote:
>>>>>
>>>>> 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 won't try to convince you otherwise, though I have my reservations,
>>>>> good to know you made it work 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
>>>>>>
>>>>>>
>>>>> yes, thanks, got it fixed, the typo, note it is very easy to do a
>>>>> resource owner flow even without the client utils, simply use WebClient
>>>>> directly and set few form parameters
>>>>>
>>>>>
>>>>>> And two more enhancement/bugs are yet to raise. One is that no way to
>>>>>> report back error from a customized loginHandler.
>>>>>>
>>>>>> OK,
>>>>>
>>>>> The other one is that AccessTokenService must require a client ID,
>>>>>> however
>>>>>> the Resource owner flow may not need the client id.
>>>>>>
>>>>>> Hmm... Lets see
>>>>>>
>>>>>
>>>>>
>>>> right, we are talking about public clients then ? You will need to
>>>> configure AccessTokenservice to support public clients, that should help
>>>>
>>>> Sergey
>>>>
>>>>
>>>> Thanks. Sergey
>>>>>
>>>>> Many thanks,
>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Tue, Nov 19, 2013 at 11:18 PM, Sergey Beryozkin
>>>>>> <sb...@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
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>> --
>>> 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
>
Re: Oauth2 implicit flow question
Posted by Sergey Beryozkin <sb...@gmail.com>.
On 19/11/13 21:48, wang lei wrote:
> Sergey, the enhancement requirement is raised here
> https://issues.apache.org/jira/browse/CXF-5402. I can see you already
> resolved it.
> This is the level of support you will not get from any premier service with
> any commercial product. Really appreciate this.
Thanks, nothing special really on our end, the issues have proved to be
very easy to solve, I'm postponing on more complex ones, and we are just
going a bit hyper-active as Dan is working on the releases right now.
>
> Yes you are right, I am using alot of my own GrantHandler, my own
> OauthUtils to make it work. Thats the painful part I talked about.
>
> Another question would be: (Let me know if you want me to start another
> thread) I need a two phase login process.
> The first one is about password and username validation, if passes, the
> Resource owner flow can grant the access token.
>
> Then I would like this token to be used to do the second phase login, for
> example, providing answer to a some questions.
> Once passed, then the token can be used to call any other services.
>
> Is there a way to achieve this with the current token structure? Is "scope"
> designed for this purpose?
>
Returned 'scope' is an optional hint to the client what exactly
Authorization Service (AS) allocated to a given access token, for
example, if the client requested a read and write access, and AS
returned 'read' only then the client can adjust its function and not to
offer the users write-related options, etc.
Re a 2-phase login, is it better be done before issuing a token ? Or may
be you can create a custom handler which will issue yet another token
after the 2nd phase passes, not really sure though, as I don;t see how
your whole application is supposed to function (as far as the
interaction with a user is concerned)
Cheers, SErgey
> Many thanks,
>
>
>
> On Wed, Nov 20, 2013 at 5:29 AM, Sergey Beryozkin <sb...@gmail.com>wrote:
>
>> I've reviewed the code and I'm certain the behavior is correct with the
>> respect to the owner flow client_id expectations.
>>
>> Basically, the spec says that if the client_id is not present then the
>> runtime needs to recognize the authenticated clients which used some other
>> mechanism, for example, the client may have used the client certificates,
>> Kerberos or something else. The CXF does not know in such cases how to map
>> an authenticated client to its Client representation and as such the
>> authenticated client has to be mapped to a client id, example, from the
>> filter, etc.
>>
>> AccessTokenService will only recognize Basic Authentication if no
>> client_id is available.
>>
>> Ad if it is is a pubic client then of course it can not authenticate and
>> as such a client_id must be available though the service needs to be
>> configured to support public clients
>>
>> I'm still curious though what you mean with
>>
>> "One is that no way to report back error from a customized loginHandler"
>>
>> You can simply throw "new NotAuthorizedException" or new
>> WebApplicationException(404) from it, or is it something else ?
>>
>> Thanks, Sergey
>>
>>
>> On 19/11/13 11:58, Sergey Beryozkin wrote:
>>
>>> On 19/11/13 11:55, Sergey Beryozkin wrote:
>>>
>>>> On 19/11/13 11:48, wang lei wrote:
>>>>
>>>>> 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 won't try to convince you otherwise, though I have my reservations,
>>>> good to know you made it work 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
>>>>>
>>>>
>>>> yes, thanks, got it fixed, the typo, note it is very easy to do a
>>>> resource owner flow even without the client utils, simply use WebClient
>>>> directly and set few form parameters
>>>>
>>>>>
>>>>> And two more enhancement/bugs are yet to raise. One is that no way to
>>>>> report back error from a customized loginHandler.
>>>>>
>>>> OK,
>>>>
>>>>> The other one is that AccessTokenService must require a client ID,
>>>>> however
>>>>> the Resource owner flow may not need the client id.
>>>>>
>>>>> Hmm... Lets see
>>>>
>>>
>>> right, we are talking about public clients then ? You will need to
>>> configure AccessTokenservice to support public clients, that should help
>>>
>>> Sergey
>>>
>>>
>>>> Thanks. Sergey
>>>>
>>>> Many thanks,
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On Tue, Nov 19, 2013 at 11:18 PM, Sergey Beryozkin
>>>>> <sb...@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" <sb...@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
>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>
>> --
>> 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
Re: Oauth2 implicit flow question
Posted by wang lei <ja...@gmail.com>.
Sergey, the enhancement requirement is raised here
https://issues.apache.org/jira/browse/CXF-5402. I can see you already
resolved it.
This is the level of support you will not get from any premier service with
any commercial product. Really appreciate this.
Yes you are right, I am using alot of my own GrantHandler, my own
OauthUtils to make it work. Thats the painful part I talked about.
Another question would be: (Let me know if you want me to start another
thread) I need a two phase login process.
The first one is about password and username validation, if passes, the
Resource owner flow can grant the access token.
Then I would like this token to be used to do the second phase login, for
example, providing answer to a some questions.
Once passed, then the token can be used to call any other services.
Is there a way to achieve this with the current token structure? Is "scope"
designed for this purpose?
Many thanks,
On Wed, Nov 20, 2013 at 5:29 AM, Sergey Beryozkin <sb...@gmail.com>wrote:
> I've reviewed the code and I'm certain the behavior is correct with the
> respect to the owner flow client_id expectations.
>
> Basically, the spec says that if the client_id is not present then the
> runtime needs to recognize the authenticated clients which used some other
> mechanism, for example, the client may have used the client certificates,
> Kerberos or something else. The CXF does not know in such cases how to map
> an authenticated client to its Client representation and as such the
> authenticated client has to be mapped to a client id, example, from the
> filter, etc.
>
> AccessTokenService will only recognize Basic Authentication if no
> client_id is available.
>
> Ad if it is is a pubic client then of course it can not authenticate and
> as such a client_id must be available though the service needs to be
> configured to support public clients
>
> I'm still curious though what you mean with
>
> "One is that no way to report back error from a customized loginHandler"
>
> You can simply throw "new NotAuthorizedException" or new
> WebApplicationException(404) from it, or is it something else ?
>
> Thanks, Sergey
>
>
> On 19/11/13 11:58, Sergey Beryozkin wrote:
>
>> On 19/11/13 11:55, Sergey Beryozkin wrote:
>>
>>> On 19/11/13 11:48, wang lei wrote:
>>>
>>>> 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 won't try to convince you otherwise, though I have my reservations,
>>> good to know you made it work 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
>>>>
>>>
>>> yes, thanks, got it fixed, the typo, note it is very easy to do a
>>> resource owner flow even without the client utils, simply use WebClient
>>> directly and set few form parameters
>>>
>>>>
>>>> And two more enhancement/bugs are yet to raise. One is that no way to
>>>> report back error from a customized loginHandler.
>>>>
>>> OK,
>>>
>>>> The other one is that AccessTokenService must require a client ID,
>>>> however
>>>> the Resource owner flow may not need the client id.
>>>>
>>>> Hmm... Lets see
>>>
>>
>> right, we are talking about public clients then ? You will need to
>> configure AccessTokenservice to support public clients, that should help
>>
>> Sergey
>>
>>
>>> Thanks. Sergey
>>>
>>> Many thanks,
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> On Tue, Nov 19, 2013 at 11:18 PM, Sergey Beryozkin
>>>> <sb...@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" <sb...@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
>>>>>
>>>>>
>>>>
>>>
>>>
>>
>>
>
> --
> Sergey Beryozkin
>
> Talend Community Coders
> http://coders.talend.com/
>
> Blog: http://sberyozkin.blogspot.com
>
Re: Oauth2 implicit flow question
Posted by Sergey Beryozkin <sb...@gmail.com>.
I've reviewed the code and I'm certain the behavior is correct with the
respect to the owner flow client_id expectations.
Basically, the spec says that if the client_id is not present then the
runtime needs to recognize the authenticated clients which used some
other mechanism, for example, the client may have used the client
certificates, Kerberos or something else. The CXF does not know in such
cases how to map an authenticated client to its Client representation
and as such the authenticated client has to be mapped to a client id,
example, from the filter, etc.
AccessTokenService will only recognize Basic Authentication if no
client_id is available.
Ad if it is is a pubic client then of course it can not authenticate and
as such a client_id must be available though the service needs to be
configured to support public clients
I'm still curious though what you mean with
"One is that no way to report back error from a customized loginHandler"
You can simply throw "new NotAuthorizedException" or new
WebApplicationException(404) from it, or is it something else ?
Thanks, Sergey
On 19/11/13 11:58, Sergey Beryozkin wrote:
> On 19/11/13 11:55, Sergey Beryozkin wrote:
>> On 19/11/13 11:48, wang lei wrote:
>>> 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 won't try to convince you otherwise, though I have my reservations,
>> good to know you made it work 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
>>
>> yes, thanks, got it fixed, the typo, note it is very easy to do a
>> resource owner flow even without the client utils, simply use WebClient
>> directly and set few form parameters
>>>
>>> And two more enhancement/bugs are yet to raise. One is that no way to
>>> report back error from a customized loginHandler.
>> OK,
>>> The other one is that AccessTokenService must require a client ID,
>>> however
>>> the Resource owner flow may not need the client id.
>>>
>> Hmm... Lets see
>
> right, we are talking about public clients then ? You will need to
> configure AccessTokenservice to support public clients, that should help
>
> Sergey
>
>>
>> Thanks. Sergey
>>
>>> Many thanks,
>>>
>>>
>>>
>>>
>>>
>>>
>>> On Tue, Nov 19, 2013 at 11:18 PM, Sergey Beryozkin
>>> <sb...@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" <sb...@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
>>>>
>>>
>>
>>
>
>
--
Sergey Beryozkin
Talend Community Coders
http://coders.talend.com/
Blog: http://sberyozkin.blogspot.com
Re: Oauth2 implicit flow question
Posted by Sergey Beryozkin <sb...@gmail.com>.
On 19/11/13 11:55, Sergey Beryozkin wrote:
> On 19/11/13 11:48, wang lei wrote:
>> 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 won't try to convince you otherwise, though I have my reservations,
> good to know you made it work 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
>
> yes, thanks, got it fixed, the typo, note it is very easy to do a
> resource owner flow even without the client utils, simply use WebClient
> directly and set few form parameters
>>
>> And two more enhancement/bugs are yet to raise. One is that no way to
>> report back error from a customized loginHandler.
> OK,
>> The other one is that AccessTokenService must require a client ID,
>> however
>> the Resource owner flow may not need the client id.
>>
> Hmm... Lets see
right, we are talking about public clients then ? You will need to
configure AccessTokenservice to support public clients, that should help
Sergey
>
> Thanks. Sergey
>
>> Many thanks,
>>
>>
>>
>>
>>
>>
>> On Tue, Nov 19, 2013 at 11:18 PM, Sergey Beryozkin
>> <sb...@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" <sb...@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
>>>
>>
>
>
Re: Oauth2 implicit flow question
Posted by Sergey Beryozkin <sb...@gmail.com>.
On 19/11/13 11:48, wang lei wrote:
> 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 won't try to convince you otherwise, though I have my reservations,
good to know you made it work 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
yes, thanks, got it fixed, the typo, note it is very easy to do a
resource owner flow even without the client utils, simply use WebClient
directly and set few form parameters
>
> And two more enhancement/bugs are yet to raise. One is that no way to
> report back error from a customized loginHandler.
OK,
> The other one is that AccessTokenService must require a client ID, however
> the Resource owner flow may not need the client id.
>
Hmm... Lets see
Thanks. Sergey
> Many thanks,
>
>
>
>
>
>
> On Tue, Nov 19, 2013 at 11:18 PM, Sergey Beryozkin <sb...@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" <sb...@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
>>
>
--
Sergey Beryozkin
Talend Community Coders
http://coders.talend.com/
Blog: http://sberyozkin.blogspot.com
Re: Oauth2 implicit flow question
Posted by wang lei <ja...@gmail.com>.
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 <sb...@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" <sb...@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
>
Re: Oauth2 implicit flow question
Posted by Sergey Beryozkin <sb...@gmail.com>.
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 <sb...@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" <sb...@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
Re: Oauth2 implicit flow question
Posted by wang lei <ja...@gmail.com>.
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.
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.
Many thanks,
On Tue, Nov 19, 2013 at 11:01 AM, Sergey Beryozkin <sb...@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" <sb...@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
>>>
>>>
>>
>
>
Re: Oauth2 implicit flow question
Posted by Sergey Beryozkin <sb...@gmail.com>.
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 <sb...@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" <sb...@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
>>
>
Re: Oauth2 implicit flow question
Posted by wang lei <ja...@gmail.com>.
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 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.
Cheers,
Jason
On Tue, Nov 19, 2013 at 1:36 AM, Sergey Beryozkin <sb...@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" <sb...@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
>
Re: Oauth2 implicit flow question
Posted by Sergey Beryozkin <sb...@gmail.com>.
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" <sb...@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
Re: Oauth2 implicit flow question
Posted by wang lei <ja...@gmail.com>.
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.
Cheers
Jason
On 19/11/2013 1:18 AM, "Sergey Beryozkin" <sb...@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
>
Re: Oauth2 implicit flow question
Posted by Sergey Beryozkin <sb...@gmail.com>.
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