https://developer.okta.com/blog/2017/06/21/what-the-heck-is-oauth
REST is, in a nutshell, HTTP commands pushing JSON packets over the network.
very clear definition!
Access tokens are the token the client uses to access the Resource Server(API) so we are the client if we are making the request
You don't need a confidential client to get an access token. You can get access tokens with public clients. They're designed to optimize for internet scale problems. Those tokens cannot be revoked since they are short lived
The other token is the refresh token. This is much longer-lived; days, months, years. This can be used to get new tokens. To get a refresh token, applications typically require confidential clients with authentication
Refresh tokens can be revoked. When revoking an application's access in a dashboard, you're killing its refresh token. This gives you the ability to force the clients to rotate secrets. What you're using your refresh token to get new access tokens and the access tokens are going over the wire to hit all the API resources. Each time you refresh your access token you get a new cryptographically signed token. Key rotation is built into the system
The OAuth spec doesn't define what a token is. It can be in whatever format you want. Usually though, you want these tokens to be JSON Web Tokens(a standard https://datatracker.ietf.org/doc/html/rfc7519)
JWT pronounced jot is a secure and trustworthy standard for token authentication. JWTs allow you to digitally sign information (referred to as claims) with a signature and can be verified at a later time with a secret signing key. To learn more about JWTs, see https://stormpath.com/blog/beginners-guide-jwts-in-java
Tokens are retrieved from endpoints on the authorization server.
Two main endpoint is authorize endpoint and token endpoint
- Authorize endpoint is where you go get consent and authorization from the user. this returns an authorization grant that says the user has consented to it. Then auth is passed to the token endpoint
- The token endpoint processes the grant and says "Great, here's your refresh token and your access token"
You can use the access token to get access to APIs. Once it expires, you'll have to go back to the token endpoint with the refresh token to get a new access token.
Enter OpenID connect
To solve the pseudo authentication problem, the best parts of OAuth 2.0, Facebook Connect, and SAML 2.0 were combined to create OpenID Connect. OpenID Connect(OIDC) extends OAuth 2.0 with a new signed id_token for the client and a UserInfo endpoint to fetch
within the OAuth paradigm, there are two token types: Access and Refresh tokens. When you first authenticate, your application is typically given both tokens. but the access token is set to expire after a short period once the initial access token has expired, the refresh token will allow your application to obtain a new access token. Refresh tokens have a set expiration, allowing for unlimited use up until that expiration poin tis reached. Both access and refresh tokens have built-in security to prevent tampering and are only valid for specific duration
Stormpath uses OAuth because it is an industry standard that can be leveraged by any compliant library. Stormpath currently support three of OAuth's grant types:
Password grand type: Provides the ability to get an access token based on a username and password
refresh grant type: Provides the ability to generate another access token based on a special refresh token
Client credentials grant type: provides the ability to exchange an API key pair for an access token.
start with JJWT
JJWT is a Java library providing end-to-end JSON Web Token creation and verification, developed by our own and maintained by a community of developers. Forever free and open-source (Apache License, Version 2.0), it was designed with a builder-focused interface hiding most of its complexity.
because of JJWT's fluent interface, the creation of the JWT is basically a three-step process:
- The definition of the internal claims of the token, list Issuer, Subject, Expiration, and ID.
- The cryptographic signing the JWT (making is a JWS)
- The compaction of the JWT to a URL-safe string
The final JWT will be a three-part Base64 encoded string signed with the specified signature algorithm using the provided key. After this point, the token is ready to be shared with the other party.
Here's an example of creating the JWT from above using the JJWT library:
String jwt = Jwts.builer().setSubject("users/TzMUocMF4p).setExpiration(new Date(1300819380))
.claim("name", "Robert token man")
.claim("scope", "self groups/admins)
.signWith(SignatureAlgorithm.HS256, "secret".getBytes("UTF-8"))
.compact();
Validating
Once you have a JWT, you typically deliver it back to the client that requested it. the client then stores it and passes the Token in requests to your application. This is usually done with either a cookie value or an authorization header in HTTP.
Validating the JWT allows you to verify its authenticity and get information about the user sending the token
