7

According to http://projects.spring.io/spring-security-oauth/docs/oauth2.html:

N.B. the Authorization endpoint /oauth/authorize (or its mapped alternative) should be protected using Spring Security so that it is only accessible to authenticated users.

Why is that? It doesn't sound right that an endpoint that will require an authorization grant to exchange for an authorization code should be secured. It's like a login page for a login page, specially when Authorization grant will be through resource owner password credentials.

Adriano
  • 389
  • 3
  • 11

1 Answers1

2

oAuth2 authorization works in two steps:

  1. User authenticates using their credentials
  2. User grants application X the authority to use their data

Step 2 happens on /oauth/authorize and step 1 happens elsewhere in your application (most likely through a form-login backed by Spring Security).

If you don't protect /oauth/authorize you will end up granting authorization without authenticating the user (or you won't because without an authenticated session you probably have no idea who the user is).

Raniz
  • 10,882
  • 1
  • 32
  • 64
  • 1
    That doesn't look like what happens on [Google's OAuth2 Playground](https://developers.google.com/oauthplayground/) – Adriano Jun 23 '15 at 03:24
  • Yes it does. If I open that page in a private window and select an API to authorize I am presented with a login prompt. – Raniz Jun 23 '15 at 03:31
  • 1
    That login prompt is offered **after** a call to /auth(orize), doesn't seem that any password was necessary. Spring security wants a password before that so it can prompt me for an authorization (another password) – Adriano Jun 23 '15 at 03:43
  • No. After you select the APIs you want to authorize it opens up a login prompt (authentication), after you've logged in you're asked if you want to give "Google OAuth 2.0 Playground" access to your data (authorization). – Raniz Jun 23 '15 at 04:23
  • 1
    Yes. That isn't the login prompt I'm talking about. The prompt you're seeing takes place **after** your client has successfully accessed /authorize, it is a redirect response you have received. The one I have problem with is the one required **to** access /authorize – Adriano Jun 23 '15 at 04:37
  • @Raniz, does it mean the `authorize` endpoint stays at the server side and the `token` at remote API one? Otherwise what the sensetive role of OAuth then, if I should to protect it using another security system anyway – WildDev May 30 '16 at 07:15
  • 1
    The point of oAuth is that your users can give access tokens to other sites that allow other sites to make calls on behalf of your users without giving away the credentials they use to log in on your site. Protecting the endpoint for this is vital since *you* need to be sure that the user is actually granting access (by logging in) and that you're granting access to the correct user. After this, your server issues an access token that can be used to make API calls on behalf of the user - *these* API endpoints are not protected by the regular login but by validating the access token you issued. – Raniz May 30 '16 at 07:56
  • @Raniz Does this also mean that it is worthless to try to configure two layer (basic+bearer) of security on top of each over ? In other words. It is not possible to secure your endpoint with both security. It has to be one or the other. This is why I can't configure the same endpoint in both http security ? – Dimitri Kopriwa Mar 20 '17 at 15:40