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