Oauth 2.0无需访问即可将访问令牌重定向到其他页面

Question

I wanted to implement a login flow where users can log on my website using

1. 3rd party Oauth providers, OR
2. Email id and password.

For point 1, I get it that

1. Grant type would be "Authorization code".
2. My website will redirect the user to 3rd party Oauth provider
3. I will get an authorization code and then access token using the code.

For point 2,

1. I will be hosting a Oauth server
2. I do not want to redirect user to a different page, so "authorization code", "client credentials" and "implicit" grant types isn't what I am looking for.
3. Which leaves me with "Resource owner password credentials".
4. If I use "Resource owner password credentials" I have to expose the client secret to the web application, which I heard is a bad idea.

My query:

1. What is the most appropriate way to get access token without redirecting the user to different page. Currently the authorization server is the server which is hosting the main application. I want this to validate a user using email and password which are stored on my website itself
2. If "Resource owner password credentials" is the way to go, what are the security implications of exposing the client secret.

I am new to Oauth so please correct me if I am wrong anywhere.

Note: My Client application is an Angular 2 app in browser.

Thanks.

Answer 1

You can use a popup sign-in window to complete the sign in with the implicit flow. This will load up the identity providers sign-in page (the /authorize endpoint), but will not do a full redirect in your browser. Then the identity provider can set the appropriate cookies and get you an access token. This is the canonical pattern for single-page apps (angular, react, etc.). Here's some reading that can give some color to the protocol (in the scope of Azure AD, but a lot of this transcends identity provider implementation details).

The resource owner password flow is generally not a good idea, but can be used in a few situations. Things like daemons apps or testing are good cases. In general, it's very brittle and won't support things like MFA or dynamic consent situations. Moreover, it's intrinsically less secure that a tradtional implicit or auth code flow. Here's a great blog post about good cases to use it in the scope of Azure AD (enterprise account identity provider).