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:

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.

Try it
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.

Try it
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.

build Under construction
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.

build Under construction
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.

build Under construction
Implicit Flow

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.

build Under construction