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