v2.1.0

New Features

Add extra parameters to the signIn method to customize the sign-in experience.

See the Authentication parameters for more details.

1. directSignIn: This parameter allows you to skip the first screen of the sign-in page and directly go to the social or enterprise SSO connectors's sign-in page.

   • social:<idp-name>: Use the specified social connector, e.g. social:google
   • sso:<connector-id>: Use the specified enterprise SSO connector, e.g. sso:123456

2. firstScreen: This parameter allows you to customize the first screen that users see when they start the authentication process. The value for this parameter can be:

   • sign_in: Allow users to directly access the sign-in page.
   • register: Allow users to directly access the registration page.
   • single_sign_on: Allow users to directly access the single sign-on (SSO) page.
   • identifier:sign_in: Allow users to directly access a page that only displays specific identifier-based sign-in methods to users.
   • identifier:register: Allow users to directly access a page that only displays specific identifier-based registration methods to users.
   • reset_password: Allow users to directly access the password reset page.

3. identifiers: Additional parameter to specify the identifier type for the first screen. This parameter is only used when the firstScreen parameter is set to identifier:sign_in, identifier:register, or reset_password. The value can be a list of the following supported identifier types:

   • email
   • phone
   • username

4. extraParams: This parameter allows you to pass additional custom parameters to the Logto sign-in page. The value for this parameter should be a Map<String, String> object.

Bug Fixes

Fix the logtoClient.getAccessToken method always fetching new access token bug.

Background:
On each token exchange request, Logto dart SDK will cache the token response in the local storage. To reduce the number of token exchange requests, the SDK should always return the cached access token if it's not expired. Only when the access token is expired, the SDK should fetch a new access token using the refresh token.
However, the current implementation always fetches a new access token even if the cached access token is not expired.

Root cause:
Previously, all the access token storage keys are generated using the combination of the token's resource, organization, and scopes values. This is to ensure that multiple access tokens can be stored in the storage without conflict.
Logto does not support narrowing down the scopes during a token exchange request, so the scopes value is always the same as the initial token request, therefore scopes is not necessary to be included in the logtoClient.getAccessToken method. Without the scopes value specified, the SDK can not locate the correct access token in the storage, which leads to always fetching a new access token.

Fix:
Remove the scope parameter from the _tokenStorage.buildAccessTokenKey and _tokenStorage.getAccessToken methods. Always get and set the access token using the resource and organization values as the key.