oauth

Refresh token is a reference token so, you can revogate it if someone stole from you. As a reference token the protocol define it to a long-lived. If you remove it from Authorization Server storage the attacker won’t be able to get a new access token again. The Authorization Server can provide a list of apps approved by the user (and that can be revogate). The usually use case is the duration session (renew the access token getting a new one without provide the credentials again)....

When there is a problem with authorization, there are 2 HTTP response status code used to let the client know a little bit more about the problem: 401 - Unauthorized The Resource Server can answers for one of the 2 scenarios: We don’t know who you are We won’t accept anymore your token because it is expired 403 - Forbidden The Resource Server answers for the scenario: We know perfectly you are but you are not allowed to get access for this resource

For the OAuth 2.1, the amount of recommended flows decreased (from 5 to 2), in which they are: Client Credentials Authorization Code with PKCE Client Credentials That flow represents the machine to machine communication, in which you don’t have “interactive” user present or, at least, you don’t care about it. It means that the user information is not necessary to get resources access, only the client information. The client sends a POST request to the token endpoint in Authorization Server....

In the year of 2005 came up the first protocol using web technologies to provide authentication and authorization with identity provider: SAML 2.0. Before that, it was feasible to do that in web applications with NTLM or Kerberos technologies putting those inside the browser to get access to resources using Active Directory, for example, as a way to have single sign-on on those applications. However, the idea with SAML 2.0 was in how could we proof the user is the user by doing requests to the browser?...