Microsoft Entra Sign-in URL Builder
Generate OAuth 2.0 authorization URLs for Microsoft Entra ID
Generate OAuth 2.0 authorization URLs for Microsoft Entra ID
This tool generates Microsoft Entra ID OAuth 2.0 authorization URLs and admin consent URLs. Simplify the process of creating properly formatted sign-in URLs for various authentication scenarios.
I created this tool after repeatedly building authentication URLs manually, encoding parameters, looking up docs - a tedious process I'd done countless times. This simple tool streamlines URL generation by providing an intuitive form interface where you can quickly fill in parameters and instantly get a properly formatted result.
Beyond just convenience, I've made this to serves as an educational resource. Each parameter includes helpful tooltips and direct links to official Microsoft documentation and OAuth specs, making it easier for developers and admins to understand OAuth 2.0 flows and test things out when working with Microsoft Entra ID authentication.
Found a bug or have a feature request? Please open an issue on GitHub. Contributions are welcome!
Report Issues on GitHubThis project is open source and available under the MIT License.
Made with for the Microsoft Entra community
.default
Static Consent
Default Scope: Used to refer generically to a resource service (API) without identifying specific permissions. If consent is necessary, using .default signals that consent should be prompted for all required permissions listed in the application registration.
⚠️ Important Limitation
Clients can't combine static (.default) consent and dynamic consent in a single request. You cannot use .default with other specific Graph permissions.
User.Read
Most Common
Read User Profile: Allows your app to read the signed-in user's basic profile information, including display name, email, and profile photo. This is the most commonly requested Graph permission.
Group.Read
User Groups
Read User's Groups: Allows your app to read group information for groups the signed-in user is a member of. More limited than Group.Read.All which requires admin consent.
Mail.Read
Sensitive
Read Email: Allows your app to read email messages in the signed-in user's mailbox. Users should understand this grants access to their email content.
Files.Read
User Files
Read User Files: Allows your app to read files that the signed-in user can access. More limited than Files.Read.All which requires admin consent for organization-wide access.
openid
Required
Essential for OIDC: This scope is required for any OpenID Connect authentication flow. It tells the authorization server that the application wants to use OIDC to verify the user's identity. Without this scope, you won't receive an ID token.
profile
Recommended
User Profile Information: Grants access to the user's basic profile information including name, family name, given name, preferred username, profile picture, and locale. This is commonly used for personalizing the user experience.
email
Common
Email Address: Provides access to the user's email address and email verification status. Essential for applications that need to contact users or use email for account management.
offline_access
Optional
Refresh Tokens: Allows your application to receive refresh tokens, enabling it to obtain new access tokens without requiring the user to sign in again. Use this for applications that need long-lived access to user data.
openid for OIDC flowsprofile for user personalizationemail if you need to contact usersoffline_access if you need persistent accesscode
Recommended
Authorization Code Flow: The most secure flow for web apps, mobile apps, and SPAs. Returns only an authorization code that must be exchanged for tokens on the back-end.
id_token
Implicit
Implicit Flow (ID Token only): Returns an ID token immediately. Used for authentication-only scenarios where you don't need to call APIs.
token
Deprecated
Implicit Flow (Access Token only): Returns an access token immediately. Deprecated for new applications due to security concerns.
code id_token
Hybrid
Hybrid Flow (Code + ID Token): Returns both an authorization code and ID token. Enables immediate user identification while maintaining security for API access.
code token
Hybrid
Hybrid Flow (Code + Access Token): Returns authorization code and access token. Provides immediate API access plus refresh capability.
id_token token
Implicit
Implicit Flow (Both Tokens): Returns both ID token and access token immediately. Deprecated for new applications.
code id_token token
Full Hybrid
Full Hybrid Flow: Returns all three: authorization code, ID token, and access token. Maximum flexibility but complex.
code with PKCE for highest securityThe response mode determines how the authorization server returns the authorization response parameters to the client application. Each mode has different security implications and use cases.
For detailed information, see the Microsoft Learn documentation and the OpenID Connect specification.
The authorization response parameters are encoded in the query string of the redirect URI.
Best for: Traditional web applications with server-side processing
Security: Parameters visible in browser history and server logs
Compatible with: All response types
The authorization response parameters are encoded in the fragment component (after #) of the redirect URI.
Best for: Single-page applications (SPAs) and mobile apps
Security: Parameters not sent to server, not logged in server logs
Compatible with: Implicit flow response types (id_token, token)
Note: Only accessible via JavaScript on the client side
The authorization response parameters are sent via HTTP POST to the redirect URI as form data.
Best for: Web applications requiring maximum security
Security: Parameters not visible in URLs, browser history, or referrer headers
Compatible with: All response types
Requirements: Server must handle POST requests at redirect URI
Choosing the Right Response Mode
The prompt parameter controls how the user interacts with the authorization server during authentication. It determines whether the user will be prompted to sign in, consent to permissions, or if the authentication should happen silently.
For detailed information, see the Microsoft Learn documentation and the OpenID Connect specification.
Forces the user to enter their credentials on that request, negating single sign-on. The user will always be prompted to sign in, even if they have a valid session.
Ensures that the user isn't shown any interactive prompt. If the user can't be signed in silently, the authorization server returns an error.
Triggers the OAuth consent dialog after the user signs in, asking the user to grant permissions to the app, even if consent was granted before.
Shows the account selection experience, allowing the user to select from among the accounts for which they have an existing session, or to add a different account.
login for high-security scenarios requiring fresh authenticationnone for silent authentication checks in SPAs or background processesconsent when permissions have changed or for complianceselect_account in multi-tenant apps or when account disambiguation is needed