What is the point in sending client_id and client_secret in SPAs to auth server?

Question

I am trying to understand some concepts in oauth and openid connect. To provide some context, let's say I am building a SPA (single page application) that talks to a bunch of microservices. A user needs to authenticate themselves (through the application) before they can access any data and the user will authenticate themselves on a trusted site.

Looking at oauth 2 and some of the suggested flows, Resource Owner Password Credentials Grant seems to be a fitting candidate.

 +----------+
 | Resource |
 |  Owner   |
 |          |
 +----------+
      v
      |    Resource Owner
     (A) Password Credentials
      |
      v
 +---------+                                  +---------------+
 |         |>--(B)---- Resource Owner ------->|               |
 |         |         Password Credentials     | Authorization |
 | Client  |                                  |     Server    |
 |         |<--(C)---- Access Token ---------<|               |
 |         |    (w/ Optional Refresh Token)   |               |
 +---------+                                  +---------------+

Some articles I have read say you should send your client_id and client_secret to the authorization server with your payload (username, password ... etc) when requesting authorization. My question is, does this hold for SPA? Can't someone just inspect your javascript and see what your client_id and client_secret? Is there any point in sending this information?

Answer 1

You're correct, a SPA on it's own cannot keep secrets or perform client authentication so there is no point in sending the client_secret.

In the OAuth2 world these clients are known as public clients or non-confidential clients in opposition to confidential clients which are able to perform client authentication, for example, a traditional server-side application that could keep a client secret in a secure way on the server-side.

Performing client authentication is not mandatory, however, you'll lose the ability to perform decisions based on knowing for sure the client identity.

Answer 2

When using OpenID Connect, using Resource Owner Password Credentials Grant should in my opinion always be a last resort. You generally don't want to encourage people to provide their credentials to anything but the Authorization server which they trust.

For a SPA you usually go for the Implicit flow. In this flow the user enters their details on the Authorization server as desired, but this server just returns a valid access token directly instead of an authorization token (which requires a client id to change into an access token)

See for instance this document about the various flows: https://www.scottbrady91.com/OpenID-Connect/OpenID-Connect-Flows

Edit

To answer your question from the comments: In OpenID Connect you must always register the redirect uri with the authorization server as part of the client registration process. It's possible to allow for more than one redirect uri, but they must/should always be specified as part of the client configuration.

Imagine what would happen if the client, when sending the user to the authentication server, could just tell it to send the token (which is sensitive as it allows you to perform actions on the user's behalf) to any address it wants. This would allow a malicious site to snoop access tokens and do bad things.

I'm not sure what you are trying to achieve, but I can imagine that if the Authorization Server is managed by you, you could add valid redirect URIs to the client configuration as part of the registration process.

The steps would then be (if I understand you correctly)

1. User creates an account
2. User specifies a domain name or something
3. The site handling the registration process (which should for security be managed by you) saves the account/domain info and registers this domain as a valid redirect URI with the Authorization server
4. User can now login using the Authorization server as the redirect domain is valid.

I hope that helps somewhat.