This forum is now a read-only archive. All commenting, posting, registration services have been turned off. Those needing community support and/or wanting to ask questions should refer to the Tag/Forum map, and to http://spring.io/questions for a curated list of stackoverflow tags that Pivotal engineers, and the community, monitor.

I am developing an application to use OAuth 2.0 where I own both the client and provider/authentication servers. I'm using OAuth in case any future website outside of our organization would like to access our provider (RESTful API), but for my usage I do not need the full process of requiring users to allow access to the data. I would like to ideally use a token within Javascript, similar to the Implicit flow, so that I can make calls within jquery code. The data is very user-specific.

Is there a way to implement the Implicit flow using Spring Security without the user having to allow access to the resources? Or, alternatively, is there a way to implement the client credentials flow that will allow me to distinguish users and retrieve a token that can be used within Javascript? From what I can tell, if I use the token retrieved from using the client credentials mechanism within Javascript it could be used by anyone to get all users' data if they know the correct URL paths.

Both client and provider use the same SSO server for sign-in, but I do not have access to the password (just username), so I don't think the resource owner password grant type would be of much use.

Comment

Is there a way to implement the Implicit flow using Spring Security without the user having to allow access to the resources? Or, alternatively, is there a way to implement the client credentials flow that will allow me to distinguish users and retrieve a token that can be used within Javascript?

There is a UserApprovalHandler that you can plug into the auth server to make whatever approval decision you want (including auto-approve per client for instance, so your internal clients get auto approved but external ones require the extra step). Example: https://github.com/cloudfoundry/uaa/...alHandler.java. That would work with implicit or auth code flows. I wouldn't try and do anything with client credentials if it actually involves a user.

Comment

There is a UserApprovalHandler that you can plug into the auth server to make whatever approval decision you want (including auto-approve per client for instance, so your internal clients get auto approved but external ones require the extra step). Example: https://github.com/cloudfoundry/uaa/...alHandler.java. That would work with implicit or auth code flows. I wouldn't try and do anything with client credentials if it actually involves a user.

I got this working, thanks!

Another question maybe someone can answer related to the Implicit flow - can/does this grant type use a consumer secret, similar to the authentication code flow? If I setup Spring Security OAuth client details on the provider side with a secret, it seems to be ignored in the Implicit flow (i.e. if a secret is not supplied by the client, it can still get access).

Thanks.

Comment

Per the spec, the implicit flow is designed to be used by untrusted clients (browser scripts), so there's not much point giving them a secret since they could reveal it to other apps running the the same device.

Comment

Per the spec, the implicit flow is designed to be used by untrusted clients (browser scripts), so there's not much point giving them a secret since they could reveal it to other apps running the the same device.

So it sounds like for really secure data I should probably be using the authentication code flow. Is there a way to use the authentication code flow and still call my api within Javascript?

Comment

I guess you could write the whole thing in JavaScript (it's just a bunch of redirects), but the whole point is that the Javascript client is inherently not secure, so you shouldn't. Maybe it's better to get the token via an auth code flow and then use JS to call an stateful endpoint that knows your token and stores it in the session (the JS client should send your cookie so it would work pretty easily).