Skip to main content

Login and Security

The features of the Subscripto Login service and use of Access and Refresh tokens and also permissions make it safe for users to use, but there are some security step, as an application owner and provider that you should consider

  • Security Checklist
  • The App Secret
  • Secure server side calls
  • Check Access token validity regularly
  • State parameter
  • Enable Strict mode
  • Use Https
  • How Redirect URI Checking Works

Security Checklist​

The App Secret​

The App Secret is used during the login flow to generate access token and the secret

  • Used in the token exchange step of OAuth
  • Must be kept server-side only — never in mobile apps or browsers
  • Should be stored securely in environment variables
  • Can be rotated if compromised
  • Treat like a password – exposure allows impersonation of the app

Secure server side calls​

  • Token exchange (auth code → access token) should only happen on backend
  • Access protected APIs using the bearer token from your server
  • Log only minimal information – never log the full token or secret
  • Use server firewalls or IP allow-lists if possible

Check Access token validity regularly​

  • Implement logic to:
  • Check expires_in timestamp
  • Refresh using the refresh token when nearing expiry
  • Call introspection endpoints (if available) to validate tokens from clients
  • Reject expired or revoked tokens with appropriate error codes

State parameter​

A unique value passed between system to ensure the response is coming from the same source where the request came.

  • The state parameter is used to prevent Cross-Site Request Forgery (CSRF)
  • A unique, unpredictable string should be:
  • Generated before the auth request
  • Stored on the client
  • Verified on return from the auth server
  • Never skip or hardcode this value

Enable Strict Mode​

  • Ensures redirect URIs must match exactly (not just domain or partial match)
  • Prevents attackers from injecting similar domains (e.g. example.attacker.com)
  • Helps avoid "open redirect" vulnerabilities
  • Recommended for all production OAuth flows

Use Https​

  • Mandatory for:

  • Authorization URLs

  • Token endpoints

  • Redirect URIs

  • Prevents MITM attacks that could expose authorization codes or tokens

  • TLS 1.2+ should be enforced

  • Never allow OAuth flow over http:// in production

How redirection works​

  • During app registration:

  • The developer specifies allowed redirect URIs

  • During the OAuth flow:

  • The redirect_uri in the request must match exactly (if strict mode is on)

  • Validation checks:

  • Match protocol (HTTPS)

  • Match domain and path exactly

  • Disallow wildcards unless explicitly configured (not recommended)

  • Any mismatch results in request rejection

DELETE BELOW

Create your first Post​

Create a file at blog/2021-02-28-greetings.md:

blog/2021-02-28-greetings.md
---
slug: greetings
title: Greetings!
authors:
  - name: Joel Marcey
    title: Co-creator of Docusaurus 1
    url: https://github.com/JoelMarcey
    image_url: https://github.com/JoelMarcey.png
  - name: Sébastien Lorber
    title: Docusaurus maintainer
    url: https://sebastienlorber.com
    image_url: https://github.com/slorber.png
tags: [greetings]
---

Congratulations, you have made your first post!

Feel free to play around and edit this post as much as you like.

A new blog post is now available at http://localhost:3000/blog/greetings.