-
Notifications
You must be signed in to change notification settings - Fork 27
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Specification of session in SDK #1391
Comments
After research, android custom chrome tab doesn't have
refs: https://github.com/openid/AppAuth-Android/blob/daeb09c/README.md
refs: https://datatracker.ietf.org/doc/html/rfc8252#page-19 After discussion with @louischan-oursky, since we cannot isolate the cookies from the client-side in Android, there is an idea that to isolate the cookies with a prefix provided through the query parameter. When the user visits an entry point (e.g. authorize endpoint/settings page) with query parameter like The cons of this approach are it adds extra complexity for features that need to handle requests from another party. e.g. SSO callback. When the SSO providers call the authgear callback, we cannot add the Still thinking if there is any other simpler approach.. |
@carmenlau @louischan-oursky What about we just support WebView anyway? Both iOS and Android have the same recommendation at AppAuth which say it is "explicitly not supported", but we know (at least on iOS) it would be needed since some users explicitly want to avoid the popup or even embed it in UI although it is against the best practices. Plus we don't have to add additional complexity p.s. On the reason why WebView was not explicitly supported, it is mainly related with 8.12 at RFC 8252; I think in summary, there are 3 reasons against that:
For our users, most of the time it is used by the same parties, so 1 is not valid; Problem is 2 and 3... So I think it is a trade off between users expectation? As long as we provide a simple to switch and viable options, I prefer we don't add additional complexity for now on our applications. |
If this is the case, maybe keep the decision to support webview. But we may want secure by default, so the default will be as following
What do you think? @chpapa @louischan-oursky |
In the product meeting on 2021-08-02, Ben raised a concern that just providing the the low-level options Sign in on the DeviceThis means the logged in session is global on the device. On iOS this translates to ASWebAuthenticationSession with Sign in within the AppThis means the logged in session is scoped to the application only. On Android this translates to WebView. On iOS, it could translate to ASWebAuthenticationSession with SummaryHow should we present the API? If we keep our low-level options, the curious developer can understand how the implementation looks like, but they need to read the documentation to achieve their intended use cases. |
In the mobile app SDK, replace the existing option
Note that the current behavior is equivalent to Since IDP session cookie is now optional, we can no longer assume the existence of the IDP session cookie. This is tracked by Additionally, the server must let the SDK to control whether the IDP session cookie is written. This is tracked by The SDK issues are tracked by |
New suggestion from @louischan-oursky
|
Naming of CredentialStorageTerry says credential usually means username and password. Banking application
Application likes Facebook
Google apps
Sharing cookie bi-directionally with system browser
All of them do not prefer Cookie because it involves implementation details. Rocky is the only developer who asked me about the directionality. ConclusionI agree with Terry that TokenStorage is better than CredentialStorage as the former is more accurate. shareSessionWithSystemBrowser seems to be the best choice we have. In short, we have
|
I agree that the "credentials" sounds like username+password. |
After listening to Ben's comments, I came up with a new API that uses platform specific terms as well as mentioning the underlying implementation. Hope that will help the developer to understand if they are familiar with the used terms. Here is the pseudo code illustrating the API import { Platform } from "react-native";
import authgear, {
AppGroupPersistentTokenStorage,
AccountManagerPersistentTokenStorage,
PersistentTokenStorage,
TransientTokenStorage,
} from "@authgear/react-native";
// When the developer is writing a banking application, they would write
authgear.configure({
tokenStorage: new TransientTokenStorage(),
});
// When the developer has a collection of apps that should share logged in session, they would write
authgear.configure({
// Platform.select is a well-known react-native idiom to write platform-specific code.
// See https://reactnative.dev/docs/platform-specific-code
// AppGroupPersistentTokenStorage mentions the iOS term App Group in its name to signify its nature.
// AccountManagerPersistentTokenStorage mentions the implementation details Android Account Manager API.
tokenStorage: Platform.select({
ios: new AppGroupPersistentTokenStorage(...),
android: new AccountManagerPersistentTokenStorage(...),
}),
});
// Otherwise PersistentTokenStorage is the default storage if storage is not specified. |
Progress
Server changes
The SDK issues are tracked by
Study
Overview of the SDK configuration
The mobile SDK has 2 options related to token storage and interaction with the system browser. (* indicates the default value)
The web SDK has 1 option related to session (* indicates the default value)
TransientTokenStorage
TransientTokenStorage stores the refresh token in memory. In other words, the end-user must authenticate themselves on app launch. This option is intended for applications like banking applications.
PersistentTokenStorage
PersistentTokenStorage stores the refresh token in app-specific storage. The is the default value. This option is intended for general applications.
AppGroupPersistentTokenStorage (iOS specific implementation)
AppGroupPersistentTokenStorage stores the refresh token in the keychain shared by apps in the same app group. We call the apps in the same app group affiliated apps. Affiliated apps share the SAME refresh token. Signing in in one app affects all affiliated apps.
AccountManagerPersistentTokenStorage (Android specific implementation)
AccountManagerPersistentTokenStorage stores the refresh token with the Android Account Manager API. The account data can only be read by apps signed by the same key. We call the apps signed by the same key affiliated apps. Affiliated apps share the SAME refresh token. Signing in in one app affects all affiliated apps.
Since affiliated apps can be opened concurrently, platform specific application lifecycle callback MUST BE set up properly by the developer to correctly reflect the state when switching app. For example, on iOS, the SDK provides applicationDidBecomeActive and sceneDidBecomeActive to sync state when app is brought to foreground.
The developer must also listen for the SDK sessionStateChange event to make sure the application is aware of the latest state.
shareSessionWithSystemBrowser = false
When shareSessionWithSystemBrowser is false, the SDK asks the server to suppress IDP session cookie. The SDK also uses an ephemeral web browser session if available.
shareSessionWithSystemBrowser = true
When shareSessionWithSystemBrowser is true, IDP session cookie is written as usual. The SDK uses a suitable webview so that the cookie is reflected in the system browser. Therefore, signing in an app will have a by-product of signing in on the web. On the other hand, if the end-user signs in on the website first, when they signs in in the app, they will see the continue screen.
Use case examples
Here we list a number of use cases and their corresponding configuration.
Use case 1: An application that requires authentication on every app launch
Typically this type of application advocates biometric authentication. The end-user authenticates with biometric.
Use case 2: Standalone mobile app
This is the most common use case, so the default values are designed to work with this use case.
Use case 3: A collection of apps that shares signed in status, e.g. The series of apps developed by Google
This is an advanced use case due to the complexity of setting up affiliated apps.
Use case 4: A website and a mobile app
A typical example is a service available both as a website and a mobile app. When the end-user signs in the mobile app, the website will also be signed in. This is useful when the website and the mobile app implements Universal link. When the end-user receive a universal link, the link will first be opened in the website (signed in). Then the end-user can choose to open in app instead. Having signed in state in the website helps tracking the end-user.
Implementation details of the options
tokenStorage is merely an option controlling how refresh token is stored. It does not affect other things.
shareSessionWithSystemBrowser is summarized as follows:
Related SDK API
The mobile SDK has only one API to log out. It is
logout()
. It always revokes the refresh token it is using.Portal changes
Right now the IDP session settings and individual application session settings are NOT co-located. It is proposed to move Session to Applications as a new pane. The title will be changed to "Configure cookie for ". Inside application configuration screen, there are 3 panes. The 1st pane contains client_id, redirect_uris and name. The 2nd pane contains refresh token settings titled as "Mobile / SPA". The 3rd pane contains post_logout_redirect_uris titled as "Cookie"
The text was updated successfully, but these errors were encountered: