OAuth is an open-standard authorization protocol or framework that describes how unrelated servers and services can safely allow authenticated access to their assets without actually sharing the initial, related, single logon credential. In authentication parlance, this is known as secure, third-party, user-agent, delegated authorization. https://www.csoonline.com/article/3216404/what-is-oauth-how-the-open-authorization-framework-works.html
The simplest example of OAuth is when you go to log onto a website and it offers one or more opportunities to log on using another website’s/service’s logon. You then click on the button linked to the other website, the other website authenticates you, and the website you were originally connecting to logs you on itself afterward using permission gained from the second website.
OpenID is another security program, but instead of basing it on authorization it is based on authentication.
Authentication is the process of verifying who a user is, while authorization is the process of verifying what they have access to.
Because regular web apps are server-side apps where the source code is not publicly exposed, they can use the Authorization Code Flow, which exchanges an Authorization Code for a token. Your app must be server-side because during this exchange, you must also pass along your application’s Client Secret, which must always be kept secure, and you will have to store it in your client.
It creates a secret (called the code verifier) by the calling application that can be verified by the authorization server. Also the calling app creates a transform value of the code verifier called the code chalenge and sends that over HTTPS to retrieve an authorization code. This prevents malicious attacks by only allowing them the authorization code, but they cannot eexchange it for a token without the code verifier.
Implicit Flow with Form Post flow uses OpenID Connect to implement web sign-in. The web app requests and obtains tokens through the front channel, without the need for secrets or extra backend calls.
With machine-to-machine apps the system authenticates and authorizes the app rather than a user. M2M apps use the Client Credentials Flow, in which they pass along their Client ID and Client Secret to authentiate themselves and get a token.
With input constrained devices that connect to the internet, rather than authenticate the user directly, the device asks the user to go to a link on their computer or smartphone and authorize the device. To do this, device apps use the Device Authorization Flow, in which they pass along their Client ID to initiate the authorization process and get a token.
NOT RECCOMMENDED
Highly trusted applications can use the Resource Owner Password Flow, which requests that users provide credentials (username and password), typically useing an interactive form. Becuase credentials are sent to the backend and can be stored for future use before being exchanged for an Access Token, it is imperative that the application is absolutely trusted with this information.
It should only be used when redirecting-based flows (like the Authorization Code Flow) cannot be used.