OAuth2.0 - How does it protect from client impersonation?

0
votes

We plan to use OAuth 2.0 in our system and we don't feel comfortable with the security level. OAuth 2 became a standard in the industry, so I suspect we might miss something :-)

We need to protect the system APIs; some of the APIs expose access to user information and some are not. The user may use the system without login, and when later does an operation that needs his indentification he is required to provide his credentials.

So, we will first use the client credentials authorization grant to identify the client. We preferred this mode since it looks more secured to use the secret key. The client is java script application that loaded to the user-agent. The flow is:

  1. The user-agent requests the application's backend to load the application
  2. The client's backend will call the authorization server to authorize the client. It will provide the client_id and the secret_key. On success an access-token will be issued.
  3. The application that will be loaded to the client will include the access-token.
  4. The client will use the token to access the system API's

Q: Anyone can use the URL of the application. If you load the application, you have the access-token in your hand. You don't need to provide client-id or any secret...it is just there. So where is the security?

For the case the user needs to be indentified we thought of using the implicit authorization grant. In that case we don't use the secret-key since it is not a secret on the client. However, anyone that knows the client_id and has a registered user can get an access-token.

Q: So, the question again is about security, how do we know that the client that accessed the system is the real client?

Thanks,

Aviram

1
apispring-securityoauth-2.0

1 Answers

0
votes

Why you care about user gets an access token? With that token, only data belong to that user are exposed to the app.

For the case the user needs to be identified: now that a backend server is already there, code flow can be used also. Both user and client are identified.

For the case the user needn't to be identified: is a proxy in the client's backend server acceptable? The access token can be hold only be the proxy, and you can make sure it is a real client. The only problem is the proxy need to check the origin of each HTTP request to make sure it comes from the same domain. The JavaScript application can add some custom headers when sends requests to proxy.