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" <[email protected]> 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
