Failing to authenticate/login using "Implicit Grant" flow

[chrisjr]

[NOOB QUESTION!]

Hi,

We are trying to secure our application using Spring Security and OAuth2. The current theory is that users will authenticate with the resource server using the Implicit Grant flow so that they will only ever see a single login screen. However, in practice, this would also seem to imply that users can never authenticate with Spring Security since they would not be logged in when they try to access the "/oauth/authorize" endpoint. Am I understanding this correctly, please? In which case, how might users authenticate with our application via untrusted clients?

e.g. this command always triggers a Spring Security exception:

$ curl -X GET http://localhost:8080/myapp/oauth/authorize?response_type=token&client_id=myapp

"User must be authenticated with Spring Security before authorization can be completed".

The alternative might be to forbid untrusted clients, and then have trusted clients use the Resource Owner Password flow instead, but I would like to be sure I am understanding this correctly.

And I suppose an underlying question here is whether trying to use the Implicit Grant flow like this is a good idea in the first place.

Thanks,
Chris

Update: My XML configuration is currently based heavily on the Sparklr2 demo server. I've created a new <http/> section for the authorize endpoint:

<http pattern="/oauth/authorize" create-session="stateless"
      authentication-manager-ref="clientAuthenticationManager" 
      xmlns="http://www.springframework.org/schema/security">
    <intercept-url pattern="/oauth/authorize" access="IS_AUTHENTICATED_ANONYMOUSLY" />
    <http-basic entry-point-ref="clientAuthenticationEntryPoint"/>
    <anonymous/>
</http>

This sort-of works, but also means that I need to add "-u myapp:mysecret" to my CURL command line in order to reach the login URL. And that can't be right.

Oh dear, I am so confused...

[Dave Syer]

/oauth/authorize is a UI endpoint so you should secure it the way you secure the rest of your UI (if there is one). Once you have authenticated you will get a cookie back from the server and a browser client will send that back with subsequest requests (which is what is missing from your curl command). If you prefer not to use cookies that basic auth is an option I suppose but it requires your users to authenticate every request, but I sense that wasn't really what you were trying to do.

[chrisjr]

/oauth/authorize is a UI endpoint so you should secure it the way you secure the rest of your UI (if there is one).

Hi, thanks for the reply. I think my confusion here is that I'm thinking how some web sites allow you to authenticate with them via your (say) Google or Facebook credentials. So logging into a web site presents the user with the Google login page instead, using the Implicit Grant flow. In this scenario, isn't the equivalent /oauth/authorize endpoint hosted by Google? So how could it be secured? Does Spring Security support this kind of functionality, please? Or am I just misunderstanding the Implicit Grant flow?

[Dave Syer]

I'm not 100% sure I know what you want to do. If you visit a client app and it redirects you to authenticate with Google, you have authenticated with Google. By itself that doesn't mean you authenticated to the client app does it? Is the authorization endpoint hosted by Google? Could you host your own (e.g. sparklr)? Does it support the implicit flow? Yes to all the above, but I don't really know if that answers your question.

[chrisjr]

I'm not 100% sure I know what you want to do. If you visit a client app and it redirects you to authenticate with Google, you have authenticated with Google. By itself that doesn't mean you authenticated to the client app does it?

AFAIK, this is exactly what people are starting to do. By registering their applications with providers like Google or Facebook, they are effectively "out-sourcing" authentication so that they don't need to provide a login page of their own. It sounds like Spring Security doesn't support this - which isn't necessarily a problem. It just means that I'm chasing my own tail by trying to make it work.

[Dave Syer]

I think it just it means that you hadn't asked the right question. If you want to outsource authentication you aren't necessarily using an implicit flow (normally it's auth code). Spring Social Security is probably what you need if you want to do it with Google, but you could definitely also write code that used the OAuth2RestTemplate to get user details from Google's userinfo endpoint if you preferred (e.g. https://github.com/cloudfoundry/uaa/...ity/uaa/client). Is that the right question now?

P.S. I doubt you can do that trick you were trying earlier with curl and Google (they have quite a complicated redirection flow, as well as the cookie that you are missing), but if you add the cookie it will work with sparklr2. It doesn't get you anything that you can use to identify a user though, just an access token.

[chrisjr]

I think it just it means that you hadn't asked the right question. If you want to outsource authentication you aren't necessarily using an implicit flow (normally it's auth code). Spring Social Security is probably what you need if you want to do it with Google, but you could definitely also write code that used the OAuth2RestTemplate to get user details from Google's userinfo endpoint if you preferred (e.g. https://github.com/cloudfoundry/uaa/...ity/uaa/client). Is that the right question now?

At least one of our teams is already allowing users to authenticate via Google or Facebook, and AFAICT they are using Javascript libraries to do it. That suggests to me that they are using the Implicit flow. However, my problem is that I am trying to implement server-side OAuth2 for a separate project while struggling to reconcile my understanding of the Implicit flow with Spring Security's particular implementation of it.

I could actually get away with using just the Resource Owner Password flow instead, which I already have working just fine with Spring Security (including refresh tokens, assuming that you aren't supposed to be able to use a refresh token to request a new access token that has a narrower scope than the original access token?). However, the OAuth2 spec is full of dire warnings about the Resource Owner Password flow, making me think that I should be pursuing the Implicit flow instead.

P.S. I mean that I can successfully use CURL to request access tokens via the Resource Owner Password flow.

[Dave Syer]

OK, I see. Well there is no reason you couldn't use an implicit flow to grab a token and then use it to discover something about the user. That's not authentication in Spring Security terms though because it's all on the client - you have authenticated on the auth server however so maybe that's enough for your use case. The spec is full of dire warnings about untrusted clients as well for what it's worth.

[chrisjr]

That's not authentication in Spring Security terms though because it's all on the client - you have authenticated on the auth server however so maybe that's enough for your use case.

Our current focus is on securing the resource server that the (GWT) client application uses. We actually don't have any URL or method security on the client itself yet - using Spring Security or otherwise - and are simply assuming that we have "logged in" if the resource server returns an access token.


What can I say - it's a "Work In Progress" ;-).