You are browsing as a guest. Sign up (or log in) to start making projects!

3h 17m 39s logged

Devlog

  • Small additions to the new documentation.
  • changes how the api handles errors

BIG ADDITION

OAuth2 without PKCE.

I started working on PKCE, but I thought I should write a devlog before adding it.

  • Added a login website (I know I mentioned it last time).
  • Added a way to enable and disable OAuth2.
  • Authentication now checks whether OAuth2 is enabled. If it is, requests are authenticated using OAuth2. Tokens don’t expire yet, but that will be added soon.
  • Added endpoints for refreshing tokens and exchanging an authorization code for tokens.

How does OAuth2 work?

  1. The app redirects the user to a login page.
  2. After logging in, the website redirects the user back to the callback URL provided by the app.
  3. The app receives an authorization code, which it exchanges for two tokens: a long-lived refresh token and a short-lived access token.
  4. When the access token expires, the app can use the refresh endpoint to obtain a new access token.

What is PKCE?

I’ll write more about it once it’s added to the project. In short, PKCE protects the authorization flow by ensuring that only the application that started the login process can exchange the authorization code for tokens.

The application first generates a random secret (called a code verifier). Before the login request is sent, a hashed version of that secret (the code challenge) is sent to the server. Later, when exchanging the authorization code for tokens, the application sends the original secret. The server verifies that it matches the previously received hash before issuing any tokens.

I’ll explain the complete flow in the next devlog.

0
4

Comments 0

No comments yet. Be the first!