Building a Cursor-Powered App Devlog Part 4 Authentication: in this installment we review the authentication logic that protects our APIs and enables secure sessions for users.
In the authentication domain, the main pieces are credentials and the session. The credential represents the input needed to log in: email and password. The session is the successful result of logging in and contains two tokens: access_token and refresh_token.
The responsibility of the authentication domain is the business logic: validating credentials, generating JWT tokens, managing refresh logic, and revoking tokens. All of this is done without depending on HTTP or transport formats to keep the domain pure and testable.
Practical definition of Credential: email and password fields validated before any process. Best practices: do not store credentials, validate both fields, and verify the password against the user's stored hash. The Verify method compares the provided password with the user's encrypted password and returns an error if they do not match.
Session object: includes AccessToken and RefreshToken. AccessToken is used for API access for a short period, RefreshToken is used to obtain new access tokens. Implementing refresh token rotation is recommended for greater security and to avoid exposing sensitive details in logs.
We generate two tokens and store their metadata in Redis to have full control over each token's lifecycle. The Session object contains metadata such as exp expiration, nbf not before, jti unique identifier, user_id user identifier, and link_id that links an access token with its refresh token for joint revocation.
Tokens have time rules: the access_token is short-lived, for example 2 hours; the refresh_token lasts longer, for example 48 hours, and can be blocked for the first 2 hours using nbf to prevent premature refreshes.
Redis storage keys: access:jti and refresh:jti pointing to the corresponding metadata. Thanks to Redis we can revoke tokens instantly; if the associated entry is deleted, the token becomes invalid on the next request.
Why this architecture matters: it allows applying expiration and not before, immediate revocation, revoking both tokens using link_id, and avoiding blindly trusting client tokens. Each token is validated against Redis for greater security.
Implemented use cases: login, refresh token, and logout. In login, email and password are received and checked against a temporary hardcoded user for testing. If validation is correct, a pair of tokens is issued: access and refresh with their configured times.
In refresh token, the API receives the refresh token, validates nbf and exp, issues a new token pair, and revokes the old refresh token to make it single-use, mitigating the risk of reuse by an attacker.
In logout, the API receives the access token from the Authorization Bearer header, revokes the access token, and uses link_id to locate and revoke the associated refresh token, ensuring both tokens become unusable.
For dependency assembly we use Google Wire as a dependency injection tool. With Wire we define a UseCaseSet that groups configuration, Redis client, Redis adapter, repositories, token generator, and authentication use cases. Wire builds the final container that facilitates testing and avoids manual dependency wiring.
Advantages of this approach: eliminates manual dependency wiring, facilitates testing by swapping implementations with mocks, avoids hidden dependencies, and keeps the system modular and maintainable. UseCaseSet is the blueprint and Wire is the builder that produces a ready-to-use container.
This devlog currently uses a hardcoded user only to speed up the demonstration. The token mechanics are already production-style, and when we integrate the database, authentication will validate real users while maintaining the same session and Redis-based revocation logic.
At Q2BSTUDIO we are a software development company specialized in custom applications and custom software. We offer expertise in artificial intelligence, AI for businesses, AI agents, cybersecurity, aws and azure cloud services, business intelligence services, and power bi solutions. We integrate security, performance, and best practices to deliver scalable products aligned with business objectives.
If you are looking to integrate robust authentication into your projects or develop custom applications with artificial intelligence and cybersecurity capabilities, at Q2BSTUDIO we design secure architectures with controlled sessions, refresh token rotation, and operational visibility through Redis storage and aws and azure cloud service monitoring.
Keywords to improve positioning: custom applications custom software artificial intelligence cybersecurity aws and azure cloud services business intelligence services AI for businesses AI agents power bi.
Next steps: bring this authentication layer to the presentation level. REST endpoints and Swagger documentation will allow the outside world to consume our services securely, while we continue strengthening aspects such as auditing, metrics, and support for multiple cloud providers.
In summary, with an authentication layer based on sessions, JWT tokens, and Redis storage, plus a dependency container built with Wire, we obtain a modular, secure system ready to integrate into custom applications and artificial intelligence solutions offered by Q2BSTUDIO.
