Support for Single Sign On via Identity Providers #7
Assignees
Labels
enhancement
New feature or request
Comments
1 task
PSchmiedmayer
changed the title
Supereg
added a commit
to StanfordSpezi/SpeziAccount
that referenced
this issue
Sep 14, 2023
# Unified Account View with rethought Account Service Model ## ♻️ Current situation & Problem Currently, `SepziAccount` exposes two distinct views: `Login` and `SignUp`. While visually identical (expect for customizations), the AccountService buttons navigate to the respective Login or SignUp views for data entry. This introduces several navigation steps for the user even for simple workflows (e.g. just signing in a returning user). Further, it is not clear where to place Identity Provider buttons (e.g., Sign in with Apple), as these create a new account or just sign you in to your existing one with the same, single button. ## 💡 Proposed solution This PR makes the following changes: * Unifying `Login` and `SignUp` views to be represented by a single view, placing identity providers on the same page as regular Account Services, the `AccountSetup` view. * Restructure the Account Service Model: * Make the necessary preparations to support third-party Identity providers * Introduce the concept of an `EmbeddableAccountService` and a new `KeyPasswordBasedAccountService` as new abstraction layers. This replaces the current `UsernamePasswordAccountService` and `EmailPasswordAccountService` implementations. Those we really only Mock implementations which provided extensibility through class inheritance. This was replaced by providing the same functionality with a hierarchy of protocols being more powerful and providing much more flexibility. Further, we introduce new Mock Account services (e.g., used by PreviewProviders) which more clearly communicate their use through their updated name. * Move the UI parts of an AccountService out into a distinct abstraction layer (`AccountSetupViewStyle`s). * Introduce the `Account Value` (through `AccountKey` implementations) abstraction to support arbitrary account values * They provide a name, a category (for optimized placement in the UI), and a initial value * The provide the UI components do display (`DataDisplayView`) and setup or edit (`DataEntryView`) account values * The provide easy to use accessors using extensions on `AccountKeys` and `AccountValues` * Optimized API surface for end-users: * Exposes the `signedIn` published property (same as previously) * Exposees the `details` shared repository to access the `AccountDetails` of the currently logged in use. This also provides access to the `AccountService` and its configuration that was used to setup the user account. * Provide a new `AccountOverview` view: * Allows to view arbitrary account values * Allows to edit arbitrary account values * Provide Logout and account Removal functionality * Enabled through StanfordSpezi/Spezi#72, one can easily configure `SpeziAccount` centrally while other configured components can provide their AccountServices via [Component Communication](https://swiftpackageindex.com/stanfordspezi/spezi/documentation/spezi/component#Communication). This PR tries to provide extensive documentation for all areas. To provide some insights into the new user-facing API surface. This is how you would configure Spezi Account now: ```swift class YourAppDelegate: SpeziAppDelegate { override var configuration: Configuration { AccountConfiguration(configuration: [ // the user defines what account values are used and if they are `required`, `collected` or just `supported` .requires(\.userId), .requires(\.password), .requires(\.name), .collects(\.dateOfBirth), .collects(\.genderIdentity) ]) } } ``` Below is an example on how to use the account setup view: ```swift struct MyOnboardingView: View { var body: some View { AccountSetup { NavigationLink { // ... next view if already signed in } label: { Text("Continue") } } } } ``` Lastly, the account overview is equally as easy to use: ```swift struct MyView: View { var body: some View { AccountOverview() } } ``` ## ⚙️ Release Notes * New, unified `AccountSetup` view * New `AccountOverview` view * Introduce new `AccountService` abstraction * Support arbitrary account values through `AccountKey`-based shared repository implementation ## ➕ Additional Information ### Related PRs and Issues * This PR provides the groundwork necessary for StanfordSpezi/SpeziFirebase#7 * The updated Firebase implementation: StanfordSpezi/SpeziFirebase#8 ### Testing Substantial UI tests were updated and added. ### Reviewer Nudging As this is quite a large PR it would make sense to start reviewing by reading through the documentation. First of all reviewing the documentation itself (structure and readability). Code example on the DocC article already explain a lot of the concepts. The areas that sparked your attention, where you think that something is off or hard to understand, I would recommend to deep dive into the respective code area. ### Code of Conduct & Contributing Guidelines By submitting creating this pull request, you agree to follow our [Code of Conduct](https://github.com/StanfordSpezi/.github/blob/main/CODE_OF_CONDUCT.md) and [Contributing Guidelines](https://github.com/StanfordSpezi/.github/blob/main/CONTRIBUTING.md): - [x] I agree to follow the [Code of Conduct](https://github.com/StanfordSpezi/.github/blob/main/CODE_OF_CONDUCT.md) and [Contributing Guidelines](https://github.com/StanfordSpezi/.github/blob/main/CONTRIBUTING.md). --------- Co-authored-by: Paul Schmiedmayer <[email protected]>
NikolaiMadlener
pushed a commit
to NikolaiMadlener/SpeziAccount
that referenced
this issue
Oct 13, 2023
…ezi#7) # Unified Account View with rethought Account Service Model ## ♻️ Current situation & Problem Currently, `SepziAccount` exposes two distinct views: `Login` and `SignUp`. While visually identical (expect for customizations), the AccountService buttons navigate to the respective Login or SignUp views for data entry. This introduces several navigation steps for the user even for simple workflows (e.g. just signing in a returning user). Further, it is not clear where to place Identity Provider buttons (e.g., Sign in with Apple), as these create a new account or just sign you in to your existing one with the same, single button. ## 💡 Proposed solution This PR makes the following changes: * Unifying `Login` and `SignUp` views to be represented by a single view, placing identity providers on the same page as regular Account Services, the `AccountSetup` view. * Restructure the Account Service Model: * Make the necessary preparations to support third-party Identity providers * Introduce the concept of an `EmbeddableAccountService` and a new `KeyPasswordBasedAccountService` as new abstraction layers. This replaces the current `UsernamePasswordAccountService` and `EmailPasswordAccountService` implementations. Those we really only Mock implementations which provided extensibility through class inheritance. This was replaced by providing the same functionality with a hierarchy of protocols being more powerful and providing much more flexibility. Further, we introduce new Mock Account services (e.g., used by PreviewProviders) which more clearly communicate their use through their updated name. * Move the UI parts of an AccountService out into a distinct abstraction layer (`AccountSetupViewStyle`s). * Introduce the `Account Value` (through `AccountKey` implementations) abstraction to support arbitrary account values * They provide a name, a category (for optimized placement in the UI), and a initial value * The provide the UI components do display (`DataDisplayView`) and setup or edit (`DataEntryView`) account values * The provide easy to use accessors using extensions on `AccountKeys` and `AccountValues` * Optimized API surface for end-users: * Exposes the `signedIn` published property (same as previously) * Exposees the `details` shared repository to access the `AccountDetails` of the currently logged in use. This also provides access to the `AccountService` and its configuration that was used to setup the user account. * Provide a new `AccountOverview` view: * Allows to view arbitrary account values * Allows to edit arbitrary account values * Provide Logout and account Removal functionality * Enabled through StanfordSpezi/Spezi#72, one can easily configure `SpeziAccount` centrally while other configured components can provide their AccountServices via [Component Communication](https://swiftpackageindex.com/stanfordspezi/spezi/documentation/spezi/component#Communication). This PR tries to provide extensive documentation for all areas. To provide some insights into the new user-facing API surface. This is how you would configure Spezi Account now: ```swift class YourAppDelegate: SpeziAppDelegate { override var configuration: Configuration { AccountConfiguration(configuration: [ // the user defines what account values are used and if they are `required`, `collected` or just `supported` .requires(\.userId), .requires(\.password), .requires(\.name), .collects(\.dateOfBirth), .collects(\.genderIdentity) ]) } } ``` Below is an example on how to use the account setup view: ```swift struct MyOnboardingView: View { var body: some View { AccountSetup { NavigationLink { // ... next view if already signed in } label: { Text("Continue") } } } } ``` Lastly, the account overview is equally as easy to use: ```swift struct MyView: View { var body: some View { AccountOverview() } } ``` ## ⚙️ Release Notes * New, unified `AccountSetup` view * New `AccountOverview` view * Introduce new `AccountService` abstraction * Support arbitrary account values through `AccountKey`-based shared repository implementation ## ➕ Additional Information ### Related PRs and Issues * This PR provides the groundwork necessary for StanfordSpezi/SpeziFirebase#7 * The updated Firebase implementation: StanfordSpezi/SpeziFirebase#8 ### Testing Substantial UI tests were updated and added. ### Reviewer Nudging As this is quite a large PR it would make sense to start reviewing by reading through the documentation. First of all reviewing the documentation itself (structure and readability). Code example on the DocC article already explain a lot of the concepts. The areas that sparked your attention, where you think that something is off or hard to understand, I would recommend to deep dive into the respective code area. ### Code of Conduct & Contributing Guidelines By submitting creating this pull request, you agree to follow our [Code of Conduct](https://github.com/StanfordSpezi/.github/blob/main/CODE_OF_CONDUCT.md) and [Contributing Guidelines](https://github.com/StanfordSpezi/.github/blob/main/CONTRIBUTING.md): - [x] I agree to follow the [Code of Conduct](https://github.com/StanfordSpezi/.github/blob/main/CODE_OF_CONDUCT.md) and [Contributing Guidelines](https://github.com/StanfordSpezi/.github/blob/main/CONTRIBUTING.md). --------- Co-authored-by: Paul Schmiedmayer <[email protected]>
|
Taus is resolved as of #18 and having a fully working implementation for Sign in with Apple in StanfordBDHG/NAMS#39. The additional task of supporting other providers like Google is tracked ion #21. |
|
Thank you for all the work here @Supereg! |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Use Case
Many app developers desire to offer single sign on via identity providers such as Apple or Google. The original CardinalKit application, and all derivative projects currently have this functionality.
Problem
Currently the Spezi Account module only supports username or email and password based authentication.
Solution
Expand the Spezi Account module to support identity providers such as Apple or Google.
Alternatives considered
An alternative is to build this functionality directly into the Spezi template application, but that may not be ideal as it should be offered as part of the account module for those who are not using the template.
Additional context
No response
Code of Conduct
The text was updated successfully, but these errors were encountered: