Repository navigation
Browser sign-in with OpenID Connect: core (5/7) - #895
Merged
Merged
Conversation
… for configuration and plugins
…arty and scope checks
…etadata endpoints
… conditions, scheme always registered The derived audience and resource_metadata URL come from the store resolved for the request, never from the Host header. Resources with account conditions are refused until those checks exist. With the resource server disabled the Oidc scheme is still registered with no issuer and no keys, so endpoints naming it answer 401. authorization_servers publishes the Authority as configured, an http Authority requires RequireHttpsMetadata=false, garbage tokens log at Information, and the startup skips an uninstalled database.
…rified e-mail or registration
…e request through a request customer resolver
…fier (install and migration)
…back-office accounts; one identity per customer
…ration off by default
…OpenID Connect scheme
…ic tokens to the OpenID Connect scheme
…, staff and unverified e-mails link by password
…entication cookie
…8 and Zitadel v4.19 Web API module flag, provider switch and identity links, Keycloak resource indicators accepted with the Audience mapper, Zitadel role assertion for user_grants, client_id instead of azp, project-wide aud, and the target reading user.human.is_email_verified.
… from the provider, no password
…ication needs a password sign-in
…identity per customer enforced by the link id
…identity per customer enforced by the link id # Conflicts: # src/Business/Grand.Business.Authentication/Services/OidcCustomerResolver.cs
…sults it forwarded to the Oidc scheme
…nstead of name prefixes
…g decision per request
… instead of repeating its rule
…isabled, before any customer is resolved
…ed resource by default
…tomer resolution, Deny defaults for the Web API
…s-e2e # Conflicts: # src/Business/Grand.Business.Core/Interfaces/Authentication/IJwtBearerAuthenticationService.cs # src/Business/Grand.Business.Core/Interfaces/Customers/IUserApiService.cs # src/Core/Grand.Domain/Customers/UserApi.cs # src/Web/Grand.Web/App_Data/appsettings.json
…mment names the Store URL
…ecting fails An identity whose e-mail the provider did not verify registers with a typed password and is not connected; it connects later with that password, like an existing account. Otherwise whoever holds that identity would keep the account once the owner of the address activates it, even after a password reset. A failed connection after registration now tells the customer. The random password of a connected account is 32 random bytes.
This file contains hidden or 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
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.
Type: feature
Issue
Customers and staff should be able to sign in to the store with the same identity provider, without silent account creation and without weakening the protection against account takeover. Part 5 of the stack (base: PR 4) - the core pieces of browser sign-in.
Solution
IOidcCustomerResolver.ResolveForLogin/LinkIdentity: never registers; an existing link signs in; an existing account with a provider-verified e-mail links automatically, except back-office accounts and customers with GrandNode two-factor authentication, which (like unverified e-mails) connect once with their store password; no account leads to the registration form; registration disabled, an inactive account or an account linked to another identity is refused.IExternalRegistrationContext: the pending provider identity lives briefly (15 minutes, absolute, non-persistent) in the existingExternalAuthenticationcookie; only the server reads it./registerexternal mode: the e-mail comes from the provider (read-only, the form value is ignored). Registration type: a verified e-mail turns e-mail validation into standard, an unverified one turns standard into e-mail validation, admin approval stays approval.en_250.xml.Breaking changes
None.
RegisterValidatorandAccountController.Registertake one more injected service; without a pending identity, registration behaves exactly as before.Testing
dotnet testforGrand.Business.Authentication.Tests,Grand.Web.Common.TestsandGrand.Web.Tests- all pass.