Enabling Javascript OAuth2 login in the Spring security context

[tamama]

Hi Joe,
Greetings,

May I ask what would be the best practice to create an Authentication Object in Spring, from an authorization code provided by the Google authentication provider?

In particular, all my OAuth2 authentiaction/authorization was dealt in the client-side (Angular front-end), and I want to pass the authorization code to the Spring backend. Obviously, I would not want my user to re-authenticate via Spring OAuth2, but instead request for GoogleCredentials object via Google-OAuth2 java client, and load the user-info straight to the Authentication object (so that I can further go on with the spring security workflow to enable roles and so on...)

In fact, due to incremental authorization, my scope will change dynamically which should be dealt via the client-side to ease load on the server. Moreover, I want to look for best practices so that everything should look professional.

May I kindly ask how Spring would allow me to do so?

Kind regards,
Tamama

[tamama]

By the way, thanks for this video:
https://www.youtube.com/watch?v=llNQDoOzrtY

[jgrandja]

@tamama Have you seen this sample?

We've implemented the Authorization Code Grant, which is demonstrated in the sample. This will be released in the upcoming 5.1 release this Sep.

The Authorization Code Grant is meant to be used by confidential clients, which typically run on the server and can handle redirect-based flows. More importantly, the client can safely store it's credentials on the server unlike in a browser client (implicit).

If you plan on keeping the Angular front-end, than you need to use the implicit grant flow and I would highly recommend using Proof Key for Code Exchange. We are planning on implementing PKCE in this issue.

[tamama]

@jgrandja Thanks for your reply.

I investigated the sample, thank you. Nonetheless, we also want to align to the best practices suggested by the Google sign-in team, as indicated in this tutorial video (3-5 min):
https://www.youtube.com/watch?v=zZt8SFivjps&list=PLNYkxOF6rcIBQCKXOfi4AUtSpMj78pX5f&index=3

Essentially, the authorization code flow suggested by Google sign-in core team is simply Proof Key for Code Exchange (PKCE) -- please correct me if I am wrong.

Currently, I am trying to do the following: 1) Adding a Pre-Auth filter to intercept the HTTPS request that contains the authorization code provided by Google, 2) If everything OK, create an Object of AbstractAuthenticationToken with the corresponding authorities (for assigning roles), 3) set this to the SecurityContextHolder...

I would be very willing to share my code and implementation afterwards, if you feel that this approach would benefit the community in the future.

[vpavic]

If you plan on keeping the Angular front-end, than you need to use the implicit grant flow and I would highly recommend using Proof Key for Code Exchange. We are planning on implementing PKCE in this issue.

@jgrandja That doesn't really make sense as PKCE is specifically targeting authorization code grant flow i.e. it provides an additional mechanism of correlation between the authorization request and the token request (there's no token request with implicit grant).

Besides, the use of authorization code grant is preferred over implicit grant these days, even for native and single-page apps, as explained in #5652 (comment).

[jgrandja]

@vpavic Thanks for the correction.

you need to use the implicit grant flow and I would highly recommend using Proof Key for Code Exchange

PKCE is indeed targeted for the authorization_code grant NOT implicit.

[tlodderstedt]

Why do you limit the authorization code to confidential clients? RFC 6749 doesn't do it. Moreover, best practice for native Apps (https://tools.ietf.org/html/rfc8252) recommends use of code for native apps (typically public clients). And most likely the OAuth working group will be recommending code for browser-based apps as well (https://tools.ietf.org/html/draft-ietf-oauth-security-topics-10#section-3.1.2).