Federated Authentication Credential Encryption via Nonce
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
In federated authentication, there is no secure method for a trusted relying party to obtain and use a user's credentials, as existing protocols do not allow secure exchange of credentials between the identity provider and the relying party.
Innovation Solution
The identity provider encrypts user credentials using a nonce and client secret, generating a key through a password-based key derivation function, and sends an access token with the encrypted credentials to the relying party, which can decrypt them later, using OpenID Connect authorization code flow and JavaScript Object Notation Web Token (JWT) or Web Encryption (JWE) messages.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If federated authentication is used to allow clients to verify user identity without accessing credentials, then security is improved by keeping credentials confidential, but the ability of relying parties to securely obtain and use user credentials is lost
Solution Approach 1:
The system performs preliminary encryption of user credentials by the identity provider before transmitting them to the relying party. The credentials are encrypted using a key derived from the client secret and nonce, so that the relying party receives already-encrypted credentials that it can then decrypt using its own key material. This preliminary action enables secure credential sharing without exposing plaintext credentials during transmission.
Solution Approach 2:
The identity provider acts as an intermediary that facilitates secure credential exchange between the user and relying party. It receives credentials from the user, encrypts them using a key derived from the client secret, and transmits the encrypted credentials to the relying party. This intermediary role allows the relying party to obtain credentials securely without the user directly sharing them, while maintaining security through cryptographic protection.
2Ease of operation
If user credentials are transmitted to relying parties, then credential usability is improved, but security risks increase due to potential replay and dictionary attacks
Solution Approach 1:
The system performs preliminary encryption of user credentials by the identity provider before transmitting them to the relying party. The credentials are encrypted using a key derived from the client secret and nonce, so that the relying party receives already-encrypted credentials that it can then decrypt using its own key material. This preliminary action enables secure credential sharing without exposing plaintext credentials during transmission.
Solution Approach 2:
The system changes the parameter of credential representation from plaintext to encrypted form. By transforming credentials into encrypted data using a key derived from the client secret and nonce, the system maintains credential usability (the relying party can decrypt and use them) while eliminating the security risks associated with transmitting plaintext credentials, as encrypted credentials cannot be subjected to dictionary attacks and replay attacks are prevented through the use of unique nonces.
3Reliability
If encryption is implemented to protect user credentials during exchange, then security is improved, but system complexity increases due to key management requirements
Solution Approach 1:
The client secret serves multiple functions: it is used to derive encryption keys for protecting credentials, it authenticates the relying party to the identity provider, and it enables the relying party to decrypt received credentials. By making the client secret multi-functional, the system avoids the need for separate key management infrastructure, reducing overall system complexity while maintaining strong security through a single trusted secret.
Solution Approach 2:
The system changes the parameter of key management from requiring separate key distribution and management infrastructure to using a password-based key derivation approach. The client secret, already established in OAuth 2.0 federated authentication, is transformed into encryption keys through a key derivation function. This parameter change leverages existing authentication mechanisms rather than introducing new key management complexity.
Data Source
AI summary
Methods, apparatuses, systems, and computer-readable mediums for sharing user credentials in federated authentication are described herein. An identity provider may receive a user credential from a user device. The identity provider may receive, from a relying party, a request for an access token. The identity provider may encrypt the user credential based on a nonce that is uniquely generated for the relying party. The identity provider may send a response to the relying party. The response may include the access token, the encrypted user credential, and the nonce.