Isolation -- Encryption and/or private network (ensuring no one else can see us communicating)
Identity -- Authentication (proving you are who you say you are)
Trust -- Authorization (proving you are allowed to interact with the other party)
http.SetCookie(w, &http.Cookie{
Name: "jwt",
Value: jwt,
HttpOnly: true,
Secure: true,
SameSite: http.SameSiteStrictMode,
Expires: time.Now().Add(24 * time.Hour),
})
Resource Owner is the end user human being who owns the data
Client is the application that provides the useful service (e.g., login service which manages sessions, or terrible puns which provides daily bad puns)
Authorization server is the service that already knows the resource owner because the resource owner already has an account.
Resource server is the server that provides a service to the Client. In our case login service is getting Salesforce data for each user to help build its sessions. The bad bun service is getting contacts from the email server.
The resource server trusts the authorization server.
Response type, expected response for transaction. The client usually wants the response type of code from the authorization server.
Scope is the granular permissions wanted by the client from the resource server.
Consent is the scopes prompt that the authorization server prompts the resource owner with to confirm weather or not the client should be granted the scopes for the resource server.
Client_id and Client_secret are used as credentials for the client to authenticate with the authorization server.
Authorization code is the short lived (30 seconds or less) code that is sent back to the resource owner after he has provided his username and password. This token is only proof that the user is signed in to the authorization server, it doesn't by itself allow anyone who has access to this token to access the resource server. This prevents attacks like cross site scripting and man in the middle proxies from stealing the token and doing unwanted interactions with the resource server on the users behalf.
Access token is what is received by the client from the authorization server, after the client has presented the client_secret and the authorization_code to the authorization server.
Id token (JWT) is not Oauth2 but OIDC flow and represents identity information about the resource_owner that the client can use.
State is the CSRF token generated by the end users browser to prove the request is coming from the not evil tab. It also prevents replay attacks if the not evil tab treats the state an consumable. Meaning compare once then throw away.
Refresh token is beneficial for centralized session revocation. Regular tokens can be saved in individual server state for fast lookups but will eventually expire meaning the centralized lookup is triggered. But traffic is reduced considerable to the centralized lookup since this is time based instead of every request based. They also benefit from replay attack protection. So if the refresh token gets stolen, the authentication server can detect this when the refresh token is used more than once. This signal can be used to terminate the active session. If dealing with signed tokens you get the benefit of being able to rotate the crypto key gracefully since temp tokens will still be valid for their lifespan.
Tokens in urls are dangerous because urls end up in referer headers for other sites which now have access to them. I guess with oauth having the authorization_code is only ok since its extremely short lived.