Skip to content

fix(swift): Fixing Auth category for Gen2 #7576

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

Merged
merged 10 commits into from
May 17, 2024
6 changes: 6 additions & 0 deletions src/directory/directory.mjs
Original file line number Diff line number Diff line change
Expand Up @@ -99,6 +99,9 @@ export const directory = {
{
path: 'src/pages/[platform]/build-a-backend/auth/connect-your-frontend/sign-in/index.mdx'
},
{
path: 'src/pages/[platform]/build-a-backend/auth/connect-your-frontend/switching-authentication-flows/index.mdx'
},
{
path: 'src/pages/[platform]/build-a-backend/auth/connect-your-frontend/sign-out/index.mdx'
},
Expand Down Expand Up @@ -167,6 +170,9 @@ export const directory = {
},
{
path: 'src/pages/[platform]/build-a-backend/auth/advanced-workflows/index.mdx'
},
{
path: 'src/pages/[platform]/build-a-backend/auth/use-aws-sdk/index.mdx'
}
]
},
Expand Down
Original file line number Diff line number Diff line change
Expand Up @@ -276,70 +276,8 @@ export const auth = defineAuth({
}
});
```

[Learn more about configuring the React Authenticator component for external providers](https://ui.docs.amplify.aws/react/connected-components/authenticator/configuration#external-providers)

{/* @TODO refactor with connect-your-frontend/sign-in */}
## Set up your frontend

<Callout info>

If you are using the [Authenticator component](https://ui.docs.amplify.aws/react/connected-components/authenticator/configuration#external-providers) with Amplify, this feature works without any additional code. The guide below is for writing your own implementation.

</Callout>
<InlineFilter filters={["angular", "javascript", "nextjs", "react", "vue"]}>

Use the `signInWithRedirect` API to initiate sign-in with an external identity provider.

```ts title="src/my-client-side-js.js"
import { signInWithRedirect } from 'aws-amplify/auth';

await signInWithRedirect({
provider: 'Apple'
});
```

</InlineFilter>
<InlineFilter filters={["angular", "javascript", "nextjs", "react", "vue"]}>

### (Required for Multi-Page Applications) Complete external Sign In after Redirect

If you are developing a multi-page application, and the redirected page is not the same page that initiated the sign in, you will need to add the following code to the redirected page to ensure the sign in gets completed:

```ts title="src/my-redirected-page.ts"
import 'aws-amplify/auth/enable-oauth-listener';
import { getCurrentUser, fetchUserAttributes } from 'aws-amplify/auth';
import { Hub } from 'aws-amplify/utils';

Hub.listen("auth", ({ payload }) => {
switch (payload.event) {
case "signInWithRedirect":
const user = await getCurrentUser();
const userAttributes = await fetchUserAttributes();
console.log({user, userAttributes});
break;
case "signInWithRedirect_failure":
// handle sign in failure
break;
case "customOAuthState":
const state = payload.data; // this will be customState provided on signInWithRedirect function
console.log(state);
break;
}
});
```

<Callout>

**Note:** The listener only works on the client side in the context of a SSR-enabled project, so ensure to import the listener on the client side only. For example, in a Next.js project, you should add the above import statement to a component that renders on the client side only by `'use client'`.

</Callout>

<Accordion eyebrow="Under the hood" headingLevel="4" title="Why external Sign In needs to be explicitly handled for Multi-Page Applications">

When you import and use the `signInWithRedirect` function, it will add a listener as a side effect that will complete the external sign in when an end user is redirected back to your app. This works well in a single-page application but in a multi-page application, you might get redirected to a page that doesn't include the listener that was originally added as a side-effect. Hence you must include the specific OAuth listener on your login success page.

</Accordion>
- [Learn more about configuring the React Authenticator component for external providers](https://ui.docs.amplify.aws/react/connected-components/authenticator/configuration#external-providers)
Copy link
Contributor

@timngyn timngyn May 15, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should this filter have vue and angular even though the link is pointing to react?

</InlineFilter>

## Configure OIDC provider
Expand Down Expand Up @@ -429,6 +367,69 @@ await signInWithRedirect({
```
</InlineFilter>

<InlineFilter filters={["angular", "javascript", "nextjs", "react", "vue"]}>
{/* @TODO refactor with connect-your-frontend/sign-in */}
## Set up your frontend

<Callout info>

If you are using the [Authenticator component](https://ui.docs.amplify.aws/react/connected-components/authenticator/configuration#external-providers) with Amplify, this feature works without any additional code. The guide below is for writing your own implementation.

</Callout>

Use the `signInWithRedirect` API to initiate sign-in with an external identity provider.

```ts title="src/my-client-side-js.js"
import { signInWithRedirect } from 'aws-amplify/auth';

await signInWithRedirect({
provider: 'Apple'
});
```

</InlineFilter>
<InlineFilter filters={["angular", "javascript", "nextjs", "react", "vue"]}>

### (Required for Multi-Page Applications) Complete external Sign In after Redirect

If you are developing a multi-page application, and the redirected page is not the same page that initiated the sign in, you will need to add the following code to the redirected page to ensure the sign in gets completed:

```ts title="src/my-redirected-page.ts"
import 'aws-amplify/auth/enable-oauth-listener';
import { getCurrentUser, fetchUserAttributes } from 'aws-amplify/auth';
import { Hub } from 'aws-amplify/utils';

Hub.listen("auth", ({ payload }) => {
switch (payload.event) {
case "signInWithRedirect":
const user = await getCurrentUser();
const userAttributes = await fetchUserAttributes();
console.log({user, userAttributes});
break;
case "signInWithRedirect_failure":
// handle sign in failure
break;
case "customOAuthState":
const state = payload.data; // this will be customState provided on signInWithRedirect function
console.log(state);
break;
}
});
```

<Callout>

**Note:** The listener only works on the client side in the context of a SSR-enabled project, so ensure to import the listener on the client side only. For example, in a Next.js project, you should add the above import statement to a component that renders on the client side only by `'use client'`.

</Callout>

<Accordion eyebrow="Under the hood" headingLevel="4" title="Why external Sign In needs to be explicitly handled for Multi-Page Applications">

When you import and use the `signInWithRedirect` function, it will add a listener as a side effect that will complete the external sign in when an end user is redirected back to your app. This works well in a single-page application but in a multi-page application, you might get redirected to a page that doesn't include the listener that was originally added as a side-effect. Hence you must include the specific OAuth listener on your login success page.

</Accordion>
</InlineFilter>

## Next steps

- [Learn how to sign in with external providers](/[platform]/build-a-backend/auth/connect-your-frontend/sign-in/#sign-in-with-external-provider)
- [Learn how to sign in with external providers](/[platform]/build-a-backend/auth/connect-your-frontend/sign-in/#sign-in-with-an-external-identity-provider)
Original file line number Diff line number Diff line change
Expand Up @@ -35,12 +35,12 @@ export function getStaticProps() {

Amplify helps you secure your application while providing an easy sign-in experience for your users. This experience is influenced by your security strategy. This security strategy includes the authentication method, security credentials, and enabling additional verification when needed.

- _Authentication_ is a process to validate **who you are** (abbreviated as _AuthN_). The system that does this validation is referred to as an Identity Provider or IdP. This can be your own self-hosted IdP or a cloud service. Oftentimes, this IdP is a external provider such as Facebook, Google, or Amazon.
- _Authentication_ is a process to validate **who you are** (abbreviated as _AuthN_). The system that does this validation is referred to as an Identity Provider or IdP. This can be your own self-hosted IdP or a cloud service. Oftentimes, this IdP is a external provider such as Apple, Facebook, Google, or Amazon.
- _Authorization_ is the process of validating **what you can access** (abbreviated as _AuthZ_). This is sometimes done by looking at tokens with custom logic, predefined rules, or signed requests with policies.

Common authentication methods and associated risks include:

- external provider federation which enables easier access for your users but shares data with third parties.
- External provider federation which enables easier access for your users but shares data with third parties.

You can improve security credentials and verification for these authentication methods by:

Expand All @@ -55,7 +55,7 @@ Amplify Auth is powered by [Amazon Cognito](https://aws.amazon.com/cognito/). Am
1. [Amazon Cognito User Pools](https://docs.aws.amazon.com/cognito/latest/developerguide/cognito-user-identity-pools.html) is a full-featured user directory service to handle user registration, authentication, and account recovery
2. [Amazon Cognito Federated Identities or Identity Pools](https://docs.aws.amazon.com/cognito/latest/developerguide/cognito-identity.html) is a service used to authorize your users to interact with other AWS services

Amplify interfaces with User Pools to store your user information, including federation with other OpenID providers like Facebook and Google, and leverages federated identities to manage user access to AWS resources.
Amplify interfaces with User Pools to store your user information, including federation with other OpenID providers like Apple, Facebook, Google, or Amazon, and leverages federated identities to manage user access to AWS resources.

Authorization is often done in one of two ways:

Expand All @@ -72,7 +72,7 @@ Amazon Cognito can be customized based on your security strategy for authenticat
- Sign-in methods (including username, email, and phone) cannot be added or changed after the initial configuration. This includes both defining which attributes are used to sign in and which attributes are required. Required attributes must have a value for all users once set.
- Verification methods (including username and email) are the same as required attributes and cannot be removed once configured.
- The `sub` attribute is a unique identifier within each user pool that cannot be modified and can be used to index and search users.
- If MFA is set to **required** for all users, you will need to include MFA setup when users sign up.
- If MFA is set to **required** with phone number for all users, you will need to include MFA setup (i.e. mandating phone number) when users sign up.

Visit the [Amazon Cognito documentation](https://docs.aws.amazon.com/cognito/latest/developerguide/what-is-amazon-cognito.html) for more details on these settings, including [User pool attributes](https://docs.aws.amazon.com/cognito/latest/developerguide/user-pool-settings-attributes.html) and [Adding MFA to a user pool](https://docs.aws.amazon.com/cognito/latest/developerguide/user-pool-settings-mfa.html).

Expand Down
Loading
Loading