RFC - Auth workflows: improvements and additions

[rohandubal]

Feature Request

With the launch of AWSMobileClient, we simplified lot of authentication/ authorization workflows. We now want to extend AWSMobileClient to support additional use-cases outlined below:

As a developer:

1. AWSMobileClient functionality:

   1. I want to enable SAML based authorization
   2. I want to add social buttons in drop-in UI that launches hosted UI for the selected social provider
   3. I want to use hosted UI from showSignIn API
   4. I want to allow my end user to sign out of all devices
   5. I want to enable device remember features
   6. I want to enable developer authenticated identities flow for authorization

2. Drop-in UI in AWSMobileClient functionality:

   1. I want to disable sign up flow
   2. I want to disable forgot password flow
   3. I want to add custom input fields on the registration screen
   4. I want to customize UI elements which include Button, Label, InputBox
   5. I want to use the drop-in UI without any navigation controller
   6. I want to enable localization
   7. I want to switch text orientation from right to left instead of left to right (culture/language semantics)
   8. I want to hide logo image / show sign in screen independently
   9. I want to change the properties of logo - size, scale, fit, etc.
   10. I want to just show the registration field directly
   11. I want to just use the change password flow
   12. I want a customized main screen

Let's use this issue to track the progress of this feature. This will help us address the following issues which we have already got feature requests for:

• #1094
• #917
• #815
• #931
• #1005
• #731
• #942

As part of this work we would also like to capture your feedback on this issue. Please let us know which of the above use cases align with your requirements, since that will help us prioritize the issues. For e.g. if you want to use the drop-in without navigation controller, please comment 2.5 since that is use-case which captures it: I want to use the drop-in UI without any navigation controller.

In addition, please comment with your ideal workflow for your app. Additionally, the following are starting point questions to help guide your responses:

1. Are you using Cognito UserPools(authentication) and Cognito IdentityPools(authorization) both in your app?
2. Are you using drop-in UI in your app?
3. Do you want more functionality in drop-in UI or more/ easy-to-use APIs in AWSMobileClient to better provide functionality in your app UI?
4. Do you want to use drop-in UI as an onboarding mechanism and then move to your own UI before production or use available customizations to match drop-in UI to your app theme?
5. Do you have social providers authentication in your app?
6. How many social providers (and which) are part of your app?
7. Do you prefer native social providers' SDK(e.g. FBLoginSDK) or hosted solutions(CognitoAuth)?
8. How important is framework size?
9. Do you have more than 1 configuration for same resources in your app? (e.g. 2 UserPools for the same app based on region)
10. Do you have SAML federation in your app?
11. Do you have features to remember user device in your app?

If you have a use-case which you want us to support in AWSMobileClient for authentication/ authorization use case, please comment below so that we can discuss and update the spec.

[BillBunting]

1 iv. I want to allow my end user to sign out of all devices. That would be nice. 1 v. I want to enable device remember features That would be nice.

2 iii. I want to add custom input fields on the registration screen That would be helpful. Currently, my app has its own profile view to collect additional user information (like a public display name, Instagram account, and user bio). I could add them to the sign-up workflow on the registration screen then store them in the user's profile. Now, after the user completes the initial AWSMobileClient sign up, then, I display a secondary profile view for them to complete (whenever there is missing required data)

2 v. I want to use the drop-in UI without any navigation controller Maybe, but since my app has a navigation controller, this is not an issue for my app. However, being able to move sign-up code into the AppDelegate or other locations where nav controller is not easily available would be nice. My app calls a "checkLogin" function that also obtains the identityId prior to making calls to AWS services; passing the nav controller around is a bit tedious which often includes doing so from a background task. Currently, there is no reliable "is logged in" method that I have had success with. (I'm waiting on some bug fixes, and hope they help)

2 ix I want to change the properties of logo - size, scale, fit, etc. and xii I want a customized main screen Absolutely, the more I can customize the logo and sign-in screen to match the app's branding, so it does not look like a "cookie cutter" app, the better.

In addition, I would like direct support for Objective C. Currently, I wrap the Swift AWSMobileClient in a Swift AWSMobileClientHelper (singleton) class and make calls from Objective C through it (to abstract changes to AWSMobileClient, etc. from the remainder of the app written in Objective C, initially a MobileHub project in Objective C).

---

In addition, please comment with your ideal workflow for your app. Additionally, the following are starting point questions to help guide your responses:

Are you using Cognito UserPools(authentication) and Cognito IdentityPools(authorization) both in your app? Yes, both.

Are you using drop-in UI in your app? Yes

Do you want more functionality in drop-in UI or more/ easy-to-use APIs in AWSMobileClient to better provide functionality in your app UI? As a developer, I want to use AWSMobileClient to provide the sign-up, and sign-in functionality, so I can focus on the mission/functional code of my app without needing to develop and manage sign-in, sign-up code.

Do you want to use drop-in UI as an onboarding mechanism and then move to your own UI before production or use available customizations to match drop-in UI to your app theme? I want to customize the drop-in UI with colors and a logo or other screen attributes to match the branding of the app (and not look exactly like all the other apps using the sign-un UI)

Do you have social providers authentication in your app? Yes

How many social providers (and which) are part of your app? Facebook and Google

Do you prefer native social providers' SDK(e.g. FBLoginSDK) or hosted solutions(CognitoAuth)? No preference

How important is framework size? As long as it is reasonable.

Do you have more than 1 configuration for same resources in your app? (e.g. 2 UserPools for the same app based on region) No.

Do you have SAML federation in your app? No.

Do you have features to remember user device in your app? Not directly. (Using Pinpoint and use the identityId as a userId for saving endpoints for push notifications)

[dennispost]

Are you using Cognito UserPools(authentication) and Cognito IdentityPools(authorization) both in your app? No, only Cognito UserPools

Are you using drop-in UI in your app? No

Do you want more functionality in drop-in UI or more/ easy-to-use APIs in AWSMobileClient to better provide functionality in your app UI? No drop-in UI, but easy-to-use APIs for login, logout, password change, mfa...

Do you want to use drop-in UI as an onboarding mechanism and then move to your own UI before production or use available customizations to match drop-in UI to your app theme? I'm not using drop-in UI at all.

Do you have social providers authentication in your app? Yes

How many social providers (and which) are part of your app?

1. Facebook

Do you prefer native social providers' SDK(e.g. FBLoginSDK) or hosted solutions(CognitoAuth)? Hosted solutions

How important is framework size? As long as it is reasonable. More important are built times.

Do you have more than 1 configuration for same resources in your app? (e.g. 2 UserPools for the same app based on region) No

Do you have SAML federation in your app? No

Do you have features to remember user device in your app? Yes

[ryancrunchi]

• AWSMobileClient functionality:

  I would like to use custom auth with AWSMobileClient and if possible without interactive auth. I found interactive auth is too much interferring on how we build our view controllers flows.

• Drop-in UI in AWSMobileClient functionality:

I don't like the fact that a business logic SDK (auth) also provides UI. I prefer keeping all control on my UI.

1. Are you using Cognito UserPools(authentication) and Cognito IdentityPools(authorization) both in your app? Yes

2. Are you using drop-in UI in your app? No

3. Do you want more functionality in drop-in UI or more/ easy-to-use APIs in AWSMobileClient to better provide functionality in your app UI? No

4. Do you want to use drop-in UI as an onboarding mechanism and then move to your own UI before production or use available customizations to match drop-in UI to your app theme? No

5. Do you have social providers authentication in your app? Yes

6. How many social providers (and which) are part of your app? Facebook

7. Do you prefer native social providers' SDK(e.g. FBLoginSDK) or hosted solutions(CognitoAuth)? Prefer hosted centralized solutions if fully customizable.

8. How important is framework size? It should not pass few Mb if it only contains source code. Build time is also important.

9. Do you have more than 1 configuration for same resources in your app? (e.g. 2 UserPools for the same app based on region) No

10. Do you have SAML federation in your app? No

11. Do you have features to remember user device in your app? No

[shannon-hager-skookum]

• Drop-in UI in AWSMobileClient functionality:

3. I want to add custom input fields on the registration screen The signup fields in the drop-in UI did not match our needs the last time I checked and there was no way to fix this. Maybe it has changed?

4. I want to use the drop-in UI without any navigation controller Navigation controller is needed during sign up but I normally prefer to present a modal during app use if login is needed.

5. I want to enable localization

6. I want to switch text orientation from right to left instead of left to right (culture/language semantics) 6 & 7 are not current needs but future needs.

7. Are you using Cognito UserPools(authentication) and Cognito IdentityPools(authorization) both in your app? Cognito UserPools only.

8. Are you using drop-in UI in your app? No. It seemed to work for a very specific signup use case and that didn't match our use case.

9. Do you want more functionality in drop-in UI or more/ easy-to-use APIs in AWSMobileClient to better provide functionality in your app UI? I would rather see the effort put toward the API because I can't use the drop-in UI. If you added functionality to the UI to meet my use cases, there would be others who still couldn't use it but all of us would benefit from API updates.

10. Do you want to use drop-in UI as an onboarding mechanism and then move to your own UI before production or use available customizations to match drop-in UI to your app theme? If I used it, I would want it to match my UI. Otherwise it looks unprofessional.

11. Do you have social providers authentication in your app? No.

12. How many social providers (and which) are part of your app? None.

13. Do you prefer native social providers' SDK(e.g. FBLoginSDK) or hosted solutions(CognitoAuth)? N/A

14. How important is framework size? Medium.

15. Do you have more than 1 configuration for same resources in your app? (e.g. 2 UserPools for the same app based on region) Not yet but eventually.

16. Do you have SAML federation in your app? No.

17. Do you have features to remember user device in your app? No.

[shannon-hager-skookum]

Update after giving the drop-in UI another shot:

Requiring a navigation controller isn't a deal-breaker but it's close.

Not being able to add/remove the fields on the signup form is a deal-breaker. I'm guessing it is a deal-breaker for most cases and an inconvenience for most others.

Not having checkboxes and links to Terms of Service and Privacy Policy on the signup for is a deal-breaker. All new iOS apps require a privacy policy link. I can make a workaround signup flow that has a separate privacy policy view before or after signing up but that's not something I would do.

Field validation as it currently exists is a dealbreaker. Password requirements and the expected phone number format is a shot in the dark and validated in random order. Putting in "a" as the password and "310.555.1212" as the phone number results in this alert: Is that supposed to be an ellipsis at the end or is it requiring 2 dots? It's confusing. I add "+1'' to the phone number that so now it is "+1310.555.1212" then submit again and get this error: (Yes, that is the actual message shown to the user. Turn on voiceover and see how it sounds...) But no more messages about the phone number so I guess the phone is good now. I add a few more characters to the password so it is 6 chars long and submit again. The "InvalidParameterException" message above says "Member must have length greater than or equal to 6" but my 6-char password ("asdfgh") results in this: So I make a 7-char password ("asdfghj") and get the same error: So I make an 8-char password ("asdfghjk") and get a new error: So I change my password to "Asdfghjk" and get this error: So I change my password to "Asdfghj1" and get this error: So I change my password to "Asdfgh1!" and get this error: Ah, so my phone number wasn't actually correct; the validation isn't being tested in a logical order. No mention of the correct format, the only phone number format mentioned in any of the messages is +1992.. but that isn't helpful in this case. I replace the dots in my phone number with dashes, changing it to "+1310-555-1212" and get the same error. I change the phone number to the format that is as close to universally accepted as any I can know of: "+1 (310) 555-1212" and get the same error. I change the phone number to "+13105551212" and it works.

(Lego Batman voice: "First try!")

In summary:

• Fields validation requirements are checked in random order
• Validation is broken and/or the messages are incorrect
• The validation titles e.g. "InvalidPasswordException" are not acceptable for user-facing alert UI.
• The validation message content is similarly unsuitable in that it refers to "member" instead of "password", displays regex, etc.
• On iOS, the "OK" button should be spelled "OK" not "Ok".
• No way to tell the user the requirements before they fill in the form.
• No way to tell the user the requirements after they submit a form that fails validation, forcing them to trial-and-error their way through.

Maybe all of the above can be customized and I'm missing it, I don't see how there is a question of whether the drop-in signin/signup flow is good enough for use except in the case of internal proof-of-concept apps or apps that require sign-up elsewhere (on a web site, company ex/intranet, etc).

If this level of detail is too much for this thread, let me know where it should go and I'll create a new issue.

[mutablealligator]

Request for customizing SignUp UI (https://github.com/aws-amplify/aws-sdk-ios/issues/1277)

[wallowabk]

Here's an auth flow use case to consider:

Password-free SMS Authentication with AWS Cognito, Lambda Node.js & iOS Swift

[Gringox]

Hi team,

Is support for Cognito User Pool custom auth in AWSMobileClient on the roadmap?

Thanks.

[desokroshan]

Add support for user migration, requested in https://github.com/aws-amplify/aws-sdk-ios/issues/1651

[palpatim]

Additional customer request:

When an automatic token refresh encounters a situation where the user must sign in (e.g., the refresh token has expired), if there is no UI delegate assigned [sic--it's unclear exactly what is meant by this or how we would detect it], do not wait and ask for a sign-in flow, but rather return an error. This could be accomplished by a configuration option to suppress the "sign in wait" behavior.

[mcroker]

Are you using Cognito UserPools(authentication) and Cognito IdentityPools(authorization) both in your app?

Both

Are you using drop-in UI in your app?

No

Do you want more functionality in drop-in UI or more/ easy-to-use APIs in AWSMobileClient to better provide functionality in your app UI?

More easy to use APIs.

Do you want to use drop-in UI as an onboarding mechanism and then move to your own UI before production or use available customizations to match drop-in UI to your app theme?

Not using drop-in UI

Do you have social providers authentication in your app?

Yes

How many social providers (and which) are part of your app?

Google, Facebook, Apple

Do you prefer native social providers' SDK(e.g. FBLoginSDK) or hosted solutions(CognitoAuth)?

For mobile app prefer native (especially for SignInWithApple which is a much better experience native). But ideally would be able to use same social providers to authenticate from Web.

How important is framework size?

Do you have more than 1 configuration for same resources in your app? (e.g. 2 UserPools for the same app based on region)

No

Do you have SAML federation in your app?

No

Do you have features to remember user device in your app?

No (other than that which come via anon IDP user)

[panindravarma]

Hi team,

Is there any update on support for Cognito User Pool custom auth in AWSMobileClient?

Thanks.

[palpatim]

@panindravarma

Is there any update on support for Cognito User Pool custom auth in AWSMobileClient?

AWSMobileClient already supports User Pools custom auth.

Hope this helps.

[dakrawczyk]

Hi all, this is the closest thread I could find to password policies. I am wondering if it is possible to access the AWSModel object AWSCognitoIdentityProviderPasswordPolicyType (found here: link)

We are trying to guide the user to create a valid password in our UI (based on whatever the password policy we define) without needing to show the AWS Supplied error message, which isn't very user friendly:

validation error detected: Value at 'proposedPassword' failed to satisfy constraint: Member must have length greater than or equal to 6

[atierian]

Thanks for all of the feedback here. We're including these in the prioritization of work on Amplify Swift.