Authorization Server - Replace form Login with Another application

[bamofah]

Hi,

First of great presentation learned a lot and raised a few more questions for me.

But wanted to know about a different approach for the authorization server. Is it possible to change the authorization server to not use form login and maybe replace it with a React/Next or any other front end framework for handling that part of the flow.

Is it a good idea to do that???

[marcusdacoregio]

Hi @bamofah, I'm so happy that you liked our presentation.

Do you mean that you have a credential form in a frontend application, and with those credentials, you request the token from the authorization server?
If so, it sounds to me that you want to use a password grant_type. The OAuth 2.1 spec omits this grant_type but you can still use it with Spring Authorization Server, see spring-projects/spring-authorization-server#343 for more detail.

However, it's not secure to use this grant_type with a public client, as a javascript frontend. Instead, you may consider using the BFF (Backend for Frontend) pattern to handle the token retrieval for you, by submitting the token request to the BFF and it will go to the authorization server and request the token, providing the client_id and client_secret (securely stored in the backend).

I hope I have answered your question. Let me know if we can help with anything else.

[bamofah]

Hi I think the BFF pattern makes sense. Will need to educate myself on how that works.

I guess the main reason why I am asking about that is because all actors (SPA, APIs and Authorization Server) would be built by myself so that's why I was wondering how I could for example repurpose the example to do that.

In such a case I don't think there would be a need for consent forms etc right??

Also thanks for the quick response

[bamofah]

Ah and also just noticed how you SPA is set up. You are building it and loading it web module. Would have to check but this might not quite work with the frontend framework I was thinking of using (NextJS)

[marcusdacoregio]

Yes, to use the password grant_type you should have total trust in your client. If they are built by you that should be fine.
I'm not sure how to guide you with consent forms, maybe @sjohnr can help you with that.

You are building it and loading it web module.

We did that only to simplify the presentation demo, you can run them separately if you want.

[bamofah]

@marcusdacoregio Once again thanks for getting back so quickly (they are probably silly questions).

I guess if the Apps were run separately one would need to set up CORS at the gateway and the SPA would need to handle the callback, but if likee in this repo where you have built your own SPA, you might be able to get away without needing the consent form.....

[sjohnr]

Hi @bamofah. Thanks for the kind words about our presentation! It is my hope that it be an educational resource to the community. I believe that many many folks want to build this type of architecture with a SPA frontend, so it just made sense to us to present that.

I'm hearing a couple of different questions here:

1. Can I perform authentication in javascript code (e.g. NextJS, Angular, React.js, etc.) instead of a server-side rendered form?

Yes. Besides the password grant Marcus mentioned (not recommended) you can build an authentication API and integrate with it however you want. Easiest way to do that is enable HTTP Basic and create a no-op /login route you can invoke in the authorization server, which should create a session (on the authz server). Once you have a session in your browser (make sure your JS framework plays nice with browser sessions), you can initiate your own redirect to begin the OAuth flow. Unfortunately, that's about the cleanest solution I'm aware of for directly integrating with a login page from a SPA.

Having said that, I'd still recommend you just build a custom server-side rendered login form on the authorization server instead of trying to log in from the SPA. My opinion is that it's just unnecessary to do from JS even though it feels like the right thing to do.

2. Can I disable the consent screen?

Yes. Though it begs the question, why use oauth? But there are good reasons, I'm sure. 😉

This is a snippet modified from this project:

	@Bean
	public RegisteredClientRepository registeredClientRepository() {
		// @formatter:off
		RegisteredClient webClient = RegisteredClient.withId(UUID.randomUUID().toString())
				...
				// this disables consent
				.clientSettings(ClientSettings.builder().requireAuthorizationConsent(false).build()) 				.build();
		RegisteredClient apiClient = RegisteredClient.withId(UUID.randomUUID().toString())
				...
				.build();
		// @formatter:on

		return new InMemoryRegisteredClientRepository(webClient, apiClient);
	}

[bamofah]

@sjohnr Wow thanks for the detailed response.

In regards to the consent form part. I was thinking that wouldn't be required anymore if like I said the SPA application is built by myself and with the intention of being the only thing that accesses it.

so The flow that I was envisioning was
SPA (built by myself) -> Auth Server = to get access token
SPA -> API (also built by myself).

[sjohnr]

Understood @bamofah.

In regards to the consent form part. I was thinking that wouldn't be required anymore if like I said the SPA application is built by myself and with the intention of being the only thing that accesses it.

As I hinted earlier, I think if you're building an isolated application, you probably don't want/need to use OAuth, it may be easier/simpler to just build the authentication into your backend instead of delegating authorization to a separate system. That's why I mentioned if you are disabling consent, it may be a signal that oauth isn't needed.

Having said that, there are use cases where oauth is required without user consent, such as when you want to automatically grant some privileges from a centralized authentication system. The canonical example of this (in my mind) is Google, e.g. accounts.google.com.

so The flow that I was envisioning was
SPA (built by myself) -> Auth Server = to get access token
SPA -> API (also built by myself).

As far as calling out to the auth server from the SPA, you can definitely do it. But managing access tokens in JS code is counter to the BFF pattern demonstrated in this presentation. I would always recommend BFF vs building a public client if you have a choice, which it sounds like you do.

Any other questions? Mind if I close this?

[bamofah]

Ace thanks. can be closed. Will do some more reading. And thanks for all the pointers.