OAuth 2.0 Authorization Server Implementation: Managing Access Tokens and Refresh Tokens

The API Access Security Gap

When exposing REST APIs to third-party integrations, managing user authorization securely is essential. Developers must avoid sharing login credentials, instead utilizing short-lived access tokens.

Implementing a custom OAuth 2.0 Authorization Server ensures secure authentication management.

Token Rule: Keep Access Tokens short-lived (e.g. 1 hour). Use secure Refresh Tokens saved in database tables to request new access tokens.

Designing the Token Storage Schema

An OAuth server requires tables to track clients, authorizations, and tokens:

-- OAuth 2.0 Token storage table in late 2013
CREATE TABLE OAuthTokens (
    TokenId INT PRIMARY KEY IDENTITY(1,1),
    AccessToken VARCHAR(256) NOT NULL UNIQUE,
    RefreshToken VARCHAR(256) NOT NULL UNIQUE,
    ClientId VARCHAR(50) NOT NULL,
    UserId INT NOT NULL,
    ExpiresAt DATETIME NOT NULL,
    IsRevoked BIT DEFAULT 0
);

Cryptographic Security Guidelines

• ◆Token Entropy: Access and Refresh tokens must use high-entropy random strings (at least 256 bits) to prevent brute-force attacks.
• ◆Transport Security: The authorization server must enforce HTTPS connection rules on all endpoints without exception.
• ◆Revocation Endpoint: Allow clients to revoke tokens on logout to prevent session hijacking.