[내보내번] Next.js docs - Authentication

내보내번(내가 보려고 내가 번역한...) Next.js docs

2021년 8월 2일 기준 Next.js 공식 문서를 번역했다.

※ 영어 전공자도 해외 유학파도 아니기에 번역에는 의역, 오역, 구글 번역이 무수히 많을 수 있으며, 혼자 공식문서를 참조해가며 번역하다 보니 오타도 많을 수 있다. 정확한 내용은 공식문서를 직접 살펴보거나 다른 정보들을 더 찾아보는 것을 추천한다.

(하지만 댓글 피드백도 환영합니다😃 )

Next.js 공식문서 확인하기>>

Authentication | Next.js

 

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.

Authentication(인증)은 누가 사용자인지를 증명하는 반면 authorization(권한부여)은 사용자가 무엇에 접근할 수 있는지를 제어한다. Next.js는 각각 다른 사용 사례를 위해 설계된 여러 인증 패턴을 제공한다. 이 페이지는 당신이 자신의 제약사항에 근거하여 선택할 수 있도록 각 사례들에 대해 살펴볼 것이다. 

Authentication pattern

The first step to identifying which authentication pattern you need is understanding the data-fetching strategy you want. We can then determine which authentication providers support this strategy. There are two main patterns:

• Use static generation to server-render a loading state, followed by fetching user data client-side.
• Fetch user data server-side to eliminate a flash of unauthenticated content.

자신에게 어떤 인증 패턴이 필요한지를 식별하기 위한 첫 번째 단계는 당신이 원하는 데이터 패칭 전략을 이해하는 것이다. 그다음 이 전략을 지원하는 인증 제공자를 결정할 수 있다. 아래는 두 가지 주된 패턴이다: 

• 정적 생성을 사용하여 로딩 상태를 서버 렌더링 하고 뒤이어 사용자 데이터를 클라이언츠 측에서 가져옴
• 인증되지 않은 컨텐츠의 깜박임을 제거하기 위해서 서버 측에서 사용자 데이터를 가져옴

 

Authenticating Statically Generated Pages

Next.js automatically determines that a page is static if there are no blocking data requirements. This means the absence of getServerSideProps and getInitialProps in the page. Instead, your page can render a loading state from the server, followed by fetching the user client-side.

Next.js는 페이지에 중간에 가로막는 데이터 요구사항이 없으면 정적이라고 자동으로 판단한다. 이것은 페이지에 getServerSideProps와 getInitialProps 가 없다는 의미이다. 대신에 페이지가 서버로부터 로딩 상태를 렌더링하고 나서 클라이언트 측에서 사용자를 가져올 수 있다.

One advantage of this pattern is it allows pages to be served from a global CDN and preloaded using next/link. In practice, this results in a faster TTI (Time to Interactive).

이 패턴의 장점 한 가지는 페이지들이 글로벌 CDN으로부터 제공되고 next/link를 사용하여 프리로드 될 수 있다는 점이다. 실제로 더 빠른 TTI(Time to 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:

프로필 페이지 예제를 살펴보자. 이 페이지는 처음에 로딩 스켈레톤을 렌더한다. 사용자에 대한 요청이 끝나면 사용자의 이름을 보여준다. 

// pages/profile.js

import useUser from '../lib/useUser'
import Layout from '../components/Layout'

const Profile = () => {
  // Fetch the user client-side
  const { user } = useUser({ redirectTo: '/login' })

  // Server-render loading state
  if (!user || user.isLoggedIn === false) {
    return <Layout>Loading...</Layout>
  }

  // Once the user request finishes, show the user
  return (
    <Layout>
      <h1>Your Profile</h1>
      <pre>{JSON.stringify(user, null, 2)}</pre>
    </Layout>
  )
}

export default Profile

You can view this example in action. Check out the with-iron-session example to see how it works. 

이 예제가 동작하는 것을 볼 수 있다. 어떻게 동작하는지를 보려면 with-iron-session 예제를 확인해보라. 

 

Authenticating Server-Rendered Pages

If you export an async function called getServerSideProps from a page, Next.js will pre-render this page on each request using the data returned by getServerSideProps.

페이지에서 getServerSideProps라는 비동기 함수를 export한다면, Next.js는 이 페이지를 각 요청마다 getServerSideProps에서 받은 데이터를 사용하여 프리렌더 한다. 

export async function getServerSideProps(context) {
  return {
    props: {}, // Will be passed to the page component as props
  }
}

Let's transform the profile example to use 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.

프로필 예제를 서버 측 렌더링으로 바꿔보자. 세션이 있다면 페이지의 Profile 컴포넌트에 사용자를 prop으로 반환하라. 이 예제에서는 로딩 스켈레톤이 없다는 것에 유의하라. 

// pages/profile.js

import withSession from '../lib/session'
import Layout from '../components/Layout'

export const getServerSideProps = withSession(async function ({ req, res }) {
  // Get the user's session based on the request
  const user = req.session.get('user')

  if (!user) {
    return {
      redirect: {
        destination: '/login',
        permanent: false,
      },
    }
  }

  return {
    props: { user },
  }
})

const Profile = ({ user }) => {
  // Show the user. No loading state is required
  return (
    <Layout>
      <h1>Your Profile</h1>
      <pre>{JSON.stringify(user, null, 2)}</pre>
    </Layout>
  )
}

export default Profile

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 decreasing your TTFB (Time to First Byte), you should ensure your authentication lookup is fast. Otherwise, consider static generation.

이 패턴의 장점은 리다이렉팅 전에 인증되지 않은 컨텐츠의 깜박임을 방지할 수 있다는 것이다. getServerSideProps에서 사용자 데이터를 가져오는 것은 인증 제공자에 대한 요청이 해결될 때까지 렌더링이 차단된다는 것을 알아두는 것은 중요하다. 병목구간이 생기는 것을 방지하고 TTFB를 줄이지 위해서는 인증 조회가 빠른지 확인해야 한다. 그렇지 않다면 정적 생성을 고려해보라. 

 

Authentication Providers

Now that we've discussed authentication patterns, let's look at specific providers and explore how they're used with Next.js.

지금까지 인증 패턴에 대해 이야기 나누어봤다. 이제 특정 제공자에 대해서 Next.js와 어떻게 사용될 수 있는지 알아보자. 

Bring Your Own Database

Examples

• with-iron-session
• next-auth-example

If you have an existing database with user data, you'll likely want to utilize an open-source solution that's provider agnostic.

• If you want a low-level, encrypted, and stateless session utility use next-iron-session.
• 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.

사용자 데이터가 있는 기존 데이터베이스를 가지고 있다면 공급자에 구애받지 않는 오픈소스 솔루션을 활용하고 싶을 것이다.

• low-level, 암호화되어있고, 무상태성 세션 유틸리티를 원한다면 next-iron-session을 사용하라. 
• 내장된 제공자(구글, 페이스북, 깃헙...), JWT, JWE, 이메일/암호, 매직 링크와 그 밖의 모든 기능을 갖춘 인증 시스템을 원한다면 next-auth를 사용하라. 

Both of these libraries support either authentication pattern. If you're interested in Passport, we also have examples for it using secure and encrypted cookies:

두 라이브러리 모두 위에서 살펴본 두 가지 인증 패턴을 제공한다. Passport에 관심이 있다면 secure, 암호화된 쿠키를 사용하는 예제도 있다. 

• with-passport
• with-passport-and-next-connect

Other Providers

To see examples with other authentication providers, check out the examples folder.

다른 인증 제공자들의 예제들을 살펴보려면 examples 폴더를 확인해보라. 

Examples

• with-firebase-authentication
• with-magic
• auth0
• with-supabase-auth-realtime-db
• with-userbase
• with-supertokens
• with-nhost-auth-realtime-graphql