Welcome to OAuth 2.0 Playground
-- This playground serves as an interactive platform designed to familiarize developers and students with the - intricacies of OAuth authentication processes. Beyond just theoretical knowledge, this playground provides practical - insights into the OAuth token exchange, - callback handling, and potential pitfalls or challenges one might face during real-world integrations. The ultimate aim - is to bolster - understanding and confidence in implementing OAuth, ensuring secure and efficient user authentication and authorization - in modern web applications. -
-This project is an open-source initiative by Y Soft, as such we welcome any feedback or contributions at:
--
-
- Client side: ysoftdevs/oauth-playground-client -
- Server side: ysoftdevs/oauth-playground-server -
Flows
- -Authorization Code Flow
-- OAuth 2.0 protocol designed for web applications that can securely store client secrets. - The application directs users to an authorization server to log in and grant permissions. Upon consent, the server - issues an authorization code. The application then exchanges this code for an access token in a server-to-server - request, using its client ID, client secret, and redirection URI. This flow ensures the access token is never directly - exposed to users, offering enhanced security. It's best suited for server-side web applications with the capability to - protect the client secret. -
-PKCE
-- Proof Key for Code Exchange is a security protocol for the OAuth 2.0 authorization framework, designed to prevent - interception attacks in the authorization code flow. It's especially crucial for mobile or single-page applications - where storing a client secret securely is challenging. In PKCE, the client creates a dynamic "code verifier" and its - transformed "code challenge." The server remembers this challenge, and when the authorization code is exchanged for an - access token, the client provides the original verifier. The server validates it against the stored challenge, ensuring - added security against malicious interceptions. -
-Device Authorization Grant
-- OAuth 2.0 flow optimized for devices that either lack a browser or have limited input - capabilities, such as smart TVs, game consoles, and certain IoT devices. In this flow, the device makes a request to the - authorization server and receives a unique user code and a verification URL. The user then accesses this URL on a - separate device with a browser, like a smartphone or computer, and enters the user code. After successfully logging in - and providing consent, the device polls the authorization server to obtain an access token. This method ensures a - streamlined user experience for devices with restricted input or display capabilities, allowing them to access protected - resources without the need for intricate user interactions. -
-WebAuthn
-- This protocol leverages public key cryptography and allows users to authenticate using biometrics, mobile devices, or - FIDO security keys, instead of traditional passwords. When a user registers with a website, a unique key pair is - generated: the private key stays securely on the user's device, and the public key is registered with the website. For - subsequent logins, the website challenges the user to prove ownership of the private key, typically by prompting for a - biometric or a physical action on a security key. WebAuthn enhances user security by reducing reliance on easily - compromised passwords and defending against phishing attacks. -
-CIBA
-- Client Initiated Backchannel Authentication is a protocol extension for OAuth 2.0, tailored for scenarios where - the client, such as a financial institution or IoT device, initiates the authentication process without direct user - interaction on the client's platform. This is useful for "decoupled" authentication experiences, where, for instance, a - user might authenticate on their smartphone when prompted by a smart TV app. In CIBA, once the client requests - authentication, the authorization server prompts the user on a previously registered device, such as their mobile phone. - Upon successful authentication, the authorization server sends a token back to the client. This flow provides a seamless - and secure user experience, especially in contexts where traditional OAuth 2.0 interactions might be cumbersome or impractical. -
-Implicit Flow (deprecated)
-- OAuth 2.0 Implicit Flow was designed for browser-based applications where the client cannot maintain the confidentiality - of a secret. In this flow, after user authorization, the authorization server directly redirects the browser to the - client application with an access token in the URL fragment. However, this can expose tokens in browser history or logs, - making it less secure. Consequently, the use of Implicit Flow is being discouraged in favor of the more secure - Authorization Code Flow with PKCE in recent OAuth specifications. -
-