Implement One-Time Password logins and comprehensive token-based authentication #562
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…a and unpredictable behavior
…aredKernel and update formatting of Directory.Packages.props
…tication()/UseAuthorization()
…wnstream requests and revert for responses
…e credentials are only created once
…orresponding Telemetry events
…mand, and delete dummy authentication/{email} endpoint
# Conflicts:
# application/account-management/Api/Authentication/AuthenticationEndpoints.cs
…mous() annotation
…s, namespaces, domain and database artifacts, etc.
… a line break at the end of the JSON response
…en connecting to KeyVault
…es instead, eliminating the need for the Data Protection API
…rameters and extract shared logic for Refresh and Access token generation
…running in Azure reading key from Key Vault
…elopmentTokenSigningService
…rifying JWT authentication tokens
…tformplatform to make it more readable
…ey for signing authentication tokens, and use this in `DevelopmentTokenSigningService`
…used for token signing when running tests
tjementum
force-pushed
the
315-one-time-password-sign-in
branch
from
7f57426 to
5e04fb2
Compare
|
This was
linked to
issues
Aug 28, 2024
Closed
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Summary & Motivation
Introduce a comprehensive token-based authentication system to handle One-Time Password (OTP) logins, as well as the issuing and validation of Refresh and Access Tokens (RT/AT). The Account Management self-contained system is responsible for generating the tokens, while the AppGateway intercepts all API calls, fetches the tokens from cookies, and manages the authentication flow.
If the Access Token is valid, the AppGateway forwards it as a Bearer token to the respective self-contained system API running behind the reverse proxy gateway. If the Access Token has expired, the AppGateway uses the Refresh Token to call a refresh endpoint in the Account Management system, obtaining a new Access Token before proceeding. This ensures a seamless and secure authentication experience.
To support this setup, a 64-bit signing key is generated by the Aspire AppHost on localhost and stored in .NET user secrets, enabling all self-contained systems to validate Access Tokens. In production, a 2048-bit RSA key is generated by Bicep and stored in KeyVault. Depending on the environment, either the
DevelopmentTokenSigningServiceor theAzureTokenSigningServiceis used to sign and validate tokens.The Access Token is valid for 5 minutes and is stored in a session cookie with strict security settings, while the Refresh Token, valid for 3 months, is stored in a separate cookie. The Access Token contains essential user information, such as name, title, avatar URL, and TenantID, which is also injected as an HTML meta tag for frontend use.
The Refresh Token is designed to minimize security risks, using several key elements:
Additional Changes:
Checklist