oAuth and OpenID connect.

OAuth2, a secure and open protocol for data sharing, should be included in every app. Access to the data is made possible by this authentication and authorization standard without revealing the user’s identity or login information, protecting personal data. Token-based authorization is a feature of the OAuth2 protocol. The three parts of OAuth are the resource server, resource owner, and authorisation server. Client authorization servers are granted access to a website and a resource server by resource owners. Recourse servers verify the token using an authentication server. User roles and permissions are other names for access tokens, which describe people and their capabilities. The refresh token is replaced for a fresh access token when it expires.

• Client goes to the website and request to create an account.
• The resource owner asks to login with social account and redirect to the authentication server.
• Authorization servers issue a token to the client and client send token to resource server.
• Resource servers send token to the authorization server to validate the token.
• After that resource sever give access to the client.

There are few grant types in OAuth,

• authorization code.
• client credentials.
• implicit.
• password.
• device code.

Authorization code grant type is the widely use grant type.

Real-world use case,

Think about it: The client requests authorization from the Google server. Customer promotes my website. Following that, an authorization server sprang up, opened a dialog window, and informed me that they will be accessing your contact list. It only has access to my contact information. Therefore, I accept that. Now the code is sent by the authorization server. It is significant. It is not a token, therefore. A code, indeed. client resends the authorization server with a token request. Client claims he wants a token rather than a code. The client then sends the token to the resource server after receiving it from the authorization server. It compares the token to the authorization server for validation. The architecture plan affects the JWT token. It can validate against an authorization server even if you lack certification and keys. Sending the resources to the client after validation. If the resource owner doesn’t trust the client, this is the best option. The diagram below depicts the aforementioned scenario.

• What are the confusing points of this?

Goggle contact is Goggle and you are asking password and token are also Goggle.

Now we can get brief idea about grant types,

• Password grant type can be used when the resource owner trusts the owner and application and doesn’t hesitate to provide the credentials.
• When you don’t trust a person, you can utilize the grant type of authentication code. Also, there is a reason to have token request separately instead of sending the code first and then code back to client and get the token. But actually, happen authorization server send code to client, client send it back then authorization server sends the token to client.

The problem is that most of the time we work with web applications, and everything is available in the code. If the token is obtained directly from the front end, someone might be able to access the credentials used by the authorization server to register the client and provide the client id and secret. Only the client id is required to obtain the code. However, the client ID and secret are necessary in order to receive the token. Client credentials are visible, preventing the frontend from communicating with the authorization server, while the backend does and distributes the token. Sometimes a backend is absent and there is simply a front end. If no one is accessible to deliver the token request, use implicit flow, which makes a direct token request. You will then just receive the token and not the code going forward. OAuth is used to address the issue of not needing to share credentials with unreliable applications in order to access resources. OAuth, however, is not intended to handle authentication. But OAuth authentication was previously handled by Facebook and other technologies. There fore , this misuse turned to OpenID connect as solution.

OpenID,

Binding oidc and OAuth2 together can use these authentication or authorization content.

OpenID Connect works well with contemporary web applications that use a lot of JavaScript and have a propensity to run on a single page, such as Gmail. Mobile: Native iOS and Android mobile applications are very well supported by OpenID Connect. The client is redirected by the mobile app to the application authentication server using their client id. The application has four scopes, each of which has four functionalities: create, delete, update, and read. A token is provided to the mobile app by the client’s authorization server to enable reading of the content.

Reference :-

Krishantha Dinesh, oAuth and OpenID connect | Most confusing topic in plain english, Oct 3, 2021.