Implementing Implicit Flow without Resource User Approval (or other alternative)?

[adamc9]

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.

Thanks.

[enkhchuluun]

i'm not sure but i guess you should first use client credentials (strong trust between auth server and client) and exploiting on additional parameter for user specific things~

[Dave Syer]

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.

[adamc9]

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.

[Dave Syer]

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.

[adamc9]

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?

[Dave Syer]

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).