How to get a JWT?

Question

When reading about securing an app with JWTs, it is often said that the client initially gets a token from the server and then sends this token along with every request to the API.

This approach works great, once you have a token. As far as I can see, the default way of transferring a token is using an HTTP header, namely Authentication with Bearer as the prefix of the token as value.

But - is there also a default way of how to get the token initially? In samples you often see that this is just a simple request to and HTTP endpoint, that then returns JSON. But I was wondering whether there is something more of a standard workflow that e.g. describes what should be the name of this endpoint, as in OAuth2?

Any hints?

Answer 1

JWT is a token format which is used in security protocols like OAuth2 and OpenID Connect.

How to get the token from the authorization server depends on the grant flow you are using.

There are 4 grant flows defined in OAuth 2.0 that are intended for different clients and uses.

1. Authorization code grant

---

This grant is intended for web applications. The user's browser is redirected (HTTP 302) to the authorization server. The authorization server takes care of authenticating the user (via username/password, smartcard, 2-factor auth whatever).

The authorization server then redirect the browser back to a preregistered endpoint in the web application with a code. The web application then uses it's own credentials (client id and client secret) and the authorization code to request an access token from the authorization server.

The authorization server returns an access token and a refresh token to the web application. Note that the browser (untrusted) never sees the access token. Only the web application (trusted) has access to the access token and refresh token.

This grant is difficult to use from other clients than web applications as it's based on HTTP redirection.

2. Implicit grant

---

This grant is used for untrusted clients like JavaScript applications or 3rd party mobile clients (the ones you download from the app-store).

It also redirects a browser (or browser control) to the authorization server, but instead of returning a code to the browser after successful authentication, it returns an access token directly. Because the client is not trusted, the grant does not return a refresh token. The access token needs to be stored somewhere and is vulnerable to XSS attacks.

Even though you do not get a refresh token, some implementations do provide a way to get a new access token by communicating to the authorization server in a hidden IFRAME and using cookies to authenticate with the authorization server itself.

3. Resource Owner Password Credentials grant

---

This grant is for trusted clients, for example a desktop application or a first party mobile app with secure storage capabilities. The client application asks the user (the resource owner) for their username/password and then sends this to the authorization server to acquire an access token and refresh token.

Once the client has the access token, it can discard the password as it can use the refresh tokens to get new access tokens. This makes it more secure than basic authentication.

This grant does not depend on browser redirects and can be easily used from any application that can execute HTTP requests.

4. Client Credentials grant

---

This grant is meant to authenticate the client (application) instead of the user of the client.

In this case, the client submits its client id and secret directly to the authorization server to acquire an access and refresh token.

So basically the first two grants depend on browser-like capabilities (HTTP redirects, HTML login pages), where the other two grants only need an HTTP stack to communicate with the authorization server.