You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Authentication verifies who a user is, while authorization controls what a user can access. Next.js supports multiple authentication patterns, each designed for different use cases. This page will go through each case so that you can choose based on your constraints.
The first step to identifying which authentication pattern you need is understanding the [data-fetching strategy](/docs/basic-features/data-fetching/overview.md) you want. We can then determine which authentication providers support this strategy. There are two main patterns:
-Use [static generation](/docs/basic-features/pages.md#static-generation-recommended) to server-render a loading state, followed by fetching user data client-side.
14
-
-Fetch user data [server-side](/docs/basic-features/pages.md#server-side-rendering) to eliminate a flash of unauthenticated content.
Next.js automatically determines that a page is static if there are no blocking data requirements. This means the absence of [`getServerSideProps`](/docs/basic-features/data-fetching/get-server-side-props.md)and`getInitialProps`in the page. Instead, your page can render a loading state from the server, followed by fetching the user client-side.
One advantage of this pattern is it allows pages to be served from a global CDN and preloaded using [`next/link`](/docs/api-reference/next/link.md). In practice, this results in a faster TTI ([Time to Interactive](https://web.dev/interactive/)).
Let's look at an example for a profile page. This will initially render a loading skeleton. Once the request for a user has finished, it will show the user's name:
@@ -28,15 +28,15 @@ import useUser from '../lib/useUser'
28
28
importLayoutfrom'../components/Layout'
29
29
30
30
constProfile= () => {
31
-
//Fetch the user client-side
31
+
//クライアントサイドでユーザーを取得する
32
32
const { user } =useUser({ redirectTo:'/login' })
33
33
34
-
//Server-render loading state
34
+
//サーバーが読み込み中の状態をレンダリングする
35
35
if (!user ||user.isLoggedIn===false) {
36
36
return<Layout>Loading...</Layout>
37
37
}
38
38
39
-
//Once the user request finishes, show the user
39
+
//ユーザー取得リクエストが完了したらユーザーを表示する
40
40
return (
41
41
<Layout>
42
42
<h1>Your Profile</h1>
@@ -48,21 +48,21 @@ const Profile = () => {
48
48
exportdefaultProfile
49
49
```
50
50
51
-
You can view this [example in action](https://iron-session-example.vercel.app/). Check out the [`with-iron-session`](https://github.com/vercel/next.js/tree/canary/examples/with-iron-session)example to see how it works.
If you export an `async` function called [`getServerSideProps`](/docs/basic-features/data-fetching/get-server-side-props.md)from a page, Next.js will pre-render this page on each request using the data returned by `getServerSideProps`.
props: {}, //Will be passed to the page component as props
60
+
props: {}, // props としてページコンポートネントに渡される
61
61
}
62
62
}
63
63
```
64
64
65
-
Let's transform the profile example to use [server-side rendering](/docs/basic-features/pages#server-side-rendering). If there's a session, return `user`as a prop to the `Profile`component in the page. Notice there is not a loading skeleton in [this example](https://iron-session-example.vercel.app/).
An advantage of this pattern is preventing a flash of unauthenticated content before redirecting. It's important to note fetching user data in `getServerSideProps`will block rendering until the request to your authentication provider resolves. To prevent creating a bottleneck and increasing your TTFB ([Time to First Byte](https://web.dev/time-to-first-byte/)), you should ensure your authentication lookup is fast. Otherwise, consider [static generation](#authenticating-statically-generated-pages).
103
+
このパターンの利点は、認証前のコンテンツがリダイレクト前にフラッシュするのを防ぐことができる点です。ただ、`getServerSideProps`でユーザーデータを取得すると、認証プロバイダーがリクエストを完了するまでの間レンダリングがブロックされるということは認識しておくべきです。これがボトルネックとなってしまい、TTFB ([Time to First Byte](https://web.dev/time-to-first-byte/)) が増加してしまうことを避けるには、認証処理が高速に実行されることを確認しておかなければいけません。もしそうでないのであれば、[静的生成](#authenticating-statically-generated-pages)を検討してください。
104
104
105
-
## Authentication Providers
105
+
## 認証プロバイダー
106
106
107
-
Now that we've discussed authentication patterns, let's look at specific providers and explore how they're used with Next.js.
-If you want a low-level, encrypted, and stateless session utility use [`iron-session`](https://github.com/vercel/next.js/tree/canary/examples/with-iron-session).
122
-
-If you want a full-featured authentication system with built-in providers (Google, Facebook, GitHub…), JWT, JWE, email/password, magic links and more… use [`next-auth`](https://github.com/nextauthjs/next-auth-example).
Both of these libraries support either authentication pattern. If you're interested in [Passport](http://www.passportjs.org/), we also have examples for it using secure and encrypted cookies:
124
+
どちらの認証パターンにも上記のライブラリは対応しています。もし、[Passport](http://www.passportjs.org/) に興味があれば、安全で暗号化された cookies を使用した例も用意しています:
0 commit comments