분류 Reactjs

Auth0을 사용한 Next.js 인증 가이드

컨텐츠 정보

  • 조회 1,312 (작성일 )

본문

Auth0은 상업적인``서비스로서의 인증 ''플랫폼이지만 관대한 프리 티어를 통해 우리는 항상 이와 같은 튜토리얼을 통해 커뮤니티와 교류하는 것을 보고 싶어했습니다.


Next.js에 존재하는 다른 배포 모델에서 사용자를 인증하는 방법 (및 위치) 알아보기


거의 3 년 전 ZEIT는 단순하지만 사용자 정의 가능한 방식으로 단일 페이지 Javascript 애플리케이션을 빌드하기 위한 미니멀리스트 프레임 워크인 Next.js를 출시했습니다. SSR (Server-Side Rendering)에 대한 성능 및 기본 지원에 중점을 두어 NPM에서 주당 280,000 회 다운로드 및 GitHub에서 4 만 개 이상의 별에 도달했습니다. Next.js 쇼케이스는 Netflix, Scale.ai, Marvel, Jet 및 Auth0을 포함하여 크고 작은 회사에서 현재 사용하고 있는 프레임 워크의 성공을 확인합니다.


https://auth0.com/blog/ultimate-guide-nextjs-authentication-auth0/ 


새로운 도구, 새로운 도전 


Next.js에서 인증을 지원하는 솔루션을 제공하는 것이 플랫폼에서 가장 많이 요청 된 기능 중 하나였습니다. 그러나 왜 그렇습니까? React 및 Node.js에서 오랫동안 사용해온 도구를 사용할 수 없습니까 (예 : passport, auth0.js 등)? Next.js는 프론트 엔드와 백엔드 사이의 경계를 흐리게 하여 Next.js를 최대한 활용하려는 경우 기존 에코 시스템을 차선책으로 만듭니다.


예를 들어 Passport는 Express의 가용성에 따라 다릅니다. 또한 기술적으로 Next.js 응용 프로그램에서 Express를 사용할 수는 있지만 모든 성능 향상이 사라집니다. 빠른 콜드 스타트를 최적화하고 안정성과 확장 성을 향상 시키려면 서버리스 배포 모델로 전환해야 합니다.


Next.js로 애플리케이션을 구축하고 배포하는 방법은 여러 가지가 있으며,이 블로그 게시물에서는 이러한 사용 사례를 다루고 인증에 가장 적합한 메커니즘을 설명합니다.


Next.js에 대한 인증이란 무엇입니까? 


Next.js 애플리케이션을 빌드 할 때 다음과 같은 경우 인증이 필요할 수 있습니다.

  • 페이지에 액세스 할 때 : "내 송장"
  • API 경로에 액세스하는 경우 : /api/my/invoices
  • 애플리케이션이 사용자 대신 Next.js 애플리케이션 외부에서 호스팅 되는 API를 호출하는 경우 : www.mycompany.com에서 billing.mycompany.com/api까지

애플리케이션이 언제 어디서 인증을 요구할 수 있는지 이해 했으므로 다양한 Next.js 배포 모델에 대해 구현할 수 있는 인증 전략을 살펴 보겠습니다.


Next.js 정적 사이트 접근 


Next.js를 사용하면 Node.js 서버가 없어도 독립형 정적 응용 프로그램을 생성 할 수 있습니다. next build를 실행하면 명령이 이를 지원하는 각 페이지에 대해 HTML 파일을 생성합니다. 이 생성 된 출력을 사용하여 Now, Amazon S3 또는 Netlify와 같은 정적 호스팅 서비스에 사이트를 배포 할 수 있습니다.


Screenshot of the build command 


이 기술은 회사 공개 프론트 페이지와 같은 정적 사이트 또는 "관리 대시 보드"를 작성할 때 완전한 웹 사이트를 생성하는 데 사용될 수 있습니다. 생성 된 HTML은 단순히 응용 프로그램의 셸일 수 있습니다.이 셸을 응용 프로그램의 머리글 및 바닥 글로 생각하십시오. ZEIT 대시 보드는 다음과 같은 방법 중 가장 좋은 예 중 하나입니다.


Screenshot of ZEIT dashboard shell 

"쉘"이 제공되면 클라이언트 측에서 필요한 API를 호출하고 (사용자 정보를 전달) 사용자별 컨텐츠를 가져오고 페이지를 업데이트합니다.


Screenshot of ZEIT dashboard with user information 

이 모델은 호스팅과 관련하여 몇 가지 장점이 있습니다. 정적 호스팅 사이트 (Now, Amazon S3, Azure Blob Storage, Netlify 및 기타)는 전투 테스트를 거쳤으며 저렴하지만 더 중요한 것은 CDN에서 매우 빠르며 잘 재생됩니다.


Diagram of a Next.js Static Site Deployment 

다소 다른 한 가지는 인증 처리 방법입니다. 서버를 사용할 수 있는 모델은 Auth0과의 상호 작용을 처리하고 세션을 만들 수 있지만 이 모델에는 백엔드가 없습니다. 모든 작업은 프론트 엔드에서 발생합니다.

  1. 사용자가 Auth0으로 리디렉션됩니다.
  2. 사용자가 성공적으로 로그인하면 응용 프로그램으로 다시 리디렉션됩니다.
  3. 클라이언트 측은 Auth0과의 코드 교환을 완료하고 메모리에 저장 될 사용자의 id_token 및 access_token을 검색합니다.

Diagram illustrating the Authorization Code Exchange form the client-side 

사용 사례에 동적 콘텐츠 또는 사용자 별 콘텐츠가 필요한 경우 API와 같은 다른 콘텐츠도 배포해야 합니다. 이 API는 정적 호스팅 사이트의 일부로 실행될 수 없으므로 AWS Lambda, Heroku 또는 Now와 같은 플랫폼을 사용하여 배포 할 수 있습니다. 그런 다음 클라이언트 측은 access_token을 제공하고 동적 컨텐츠를 가져오고 정적 호스팅 플랫폼이 제공 한 페이지를 보강하여 해당 API와 직접 대화합니다.


Diagram of the client-side making calls to an API 


그리고 이것은 애플리케이션이 실제 "백엔드"를 갖지 않고 대신 하나 이상의 API를 호출하는 단일 페이지 애플리케이션을 빌드 하는 방법과 매우 유사합니다. 이 유형의 응용 프로그램에 로그인하는 방법에 대한 커뮤니티의 다양한 예를 찾을 수 있습니다.


import { Auth0Provider } from 'use-auth0-hooks';


export default class Root extends App {

  render () {

    const { Component, pageProps } = this.props;

    return (

      <Auth0Provider

        domain={'sandrino-dev.auth0.com'}

        clientId={'9f6ClmBt37ZGCXNqToPbefKmzVBSOLa2'}

        redirectUri={'http://localhost:3000/'}>

          <Component {...pageProps} />

      </Auth0Provider>

    );

  }

}


그런 다음 React Hooks를 사용하여 사용자를 검색하고 API 중 하나에 대한 액세스 토큰을 요청할 수 있습니다. React 애플리케이션에서 Next.js를 사용하는 방법에 대해 자세히 알아 보려면 여기로 이동하십시오. 그런 다음 API를 호출 할 때 access_token이 전송되며 다음 예제는 useApi 후크를 통해 수행됩니다.


import { useAuth } from 'use-auth0-hooks';


export default function MyShows() {

  const { isAuthenticated, isLoading, accessToken } = useAuth({

    audience: 'https://api/tv-shows',

    scope: 'read:shows'

  });


  if (!isAuthenticated) {

    return (

      <div>You must first sign in to access your subscriptions.</div>;

    )

  }


  if (isLoading) {

    return (

      <div>Loading your user information...</div>

    );

  }


  const { response, loading } = useApi(

    `${process.env.API_BASE_URL}/api/my/shows`,

    accessToken

  );


  if (loading) {

    return (

      <h1>Subscriptions for {user.email}<h1>

      <div>Loading your subscriptions ...</div>

    );

  }


  return (

    <h1>Subscriptions for {user.email}<h1>

    <div>You have subscribed to a total of {response && response.shows && response.shows.length} shows...</div>

  );

}


커튼 뒤에서 정확히 어떻게 됩니까?


auth0-spa-js를 사용하는 경우 사용자는 PKCE와 함께 Authorization Code Grant를 사용하여 로그인합니다. 높은 수준에서 사용자는 필요한 모든 인증 및 권한 부여 논리 (가입, 로그인, MFA, 동의 등)를 처리 할 Auth0으로 리디렉션 됩니다. 사용자가 Auth0을 사용하여 인증 프로세스를 완료하면 사용자는 쿼리 문자열에 인증 코드를 사용하여 응용 프로그램으로 다시 리디렉션 됩니다.

클라이언트 측은 해당 코드를 id_token 및 선택적으로 access_token (1,2)으로 교환합니다. 그런 다음 access_token을 사용하여 API를 호출 할 수 있습니다. access_token이 만료되면 <iframe>을 사용하여 커버 아래에서 동일한 흐름이 다시 발생합니다. 이 "자동 인증"접근 방식은 사용자가 Auth0에 세션을 가지고 있는 한 사용자가 로그인하는 동안 계속 작동합니다. Auth0의 사용자 세션이 만료되거나 로그 아웃하면 이 호출이 실패하고 사용자는 다시 로그인해야 합니다.


Authorization Code Exchange from the client side 


Next.js 서버리스 배포 모델 


Next.js가 빛나는 곳은 서버리스 배포 모델에서 모든 페이지와 API 경로는 예를 들어 ZEIT Now 또는 AWS Lambda를 사용하여 구현 된 별도의 서버리스 기능으로 배포됩니다.


이 모델에서는 Express.js와 같은 완전한 웹 프레임 워크가 실행되지 않지만 대신 런타임에 요청과 응답 객체 ((req, res) => {}를 전달하여 함수를 실행합니다. ). 이것이 바로 우리가 Express.js와 같은 전통적인 웹 프레임 워크 나 Passport.js와 같은 사용자 인증 및 세션 생성 (익스프레스 세션)을 위해 제공하는 빌딩 블록을 사용할 수 없는 이유입니다.


다음 다이어그램은 이 모델의 작동 방식을 보여줍니다. Next.js 페이지와 API 경로는 모두 별도의 서버리스 기능으로 실행됩니다. 브라우저가 TV 쇼 페이지 (1)에 액세스하려고 하면 기능이 페이지 렌더링을 처리하고 서버 측 렌더링을 효과적으로 수행합니다. 이 함수는 필요한 데이터를 가져 오는 데 필요한 API도 호출합니다 (2).


Next.js Serverless Deployment Diagram 


전체 사이트가 이미 로드 된 경우 다른 페이지를 방문 할 때마다 모든 렌더링이 클라이언트에서 수행됩니다. 이때 모든 API 호출은 브라우저에서 직접 이루어집니다. 보시다시피, 이것은 프론트 엔드 레이어와 백엔드 레이어 사이의 선이 흐려지기 시작하는 곳입니다.


Next.js SSR and API Call Diagram 

이제는 구체적인 내용을 다루기 전에 사용자의 사용 가능한 위치에 따라 인증과 관련하여 서버리스 모델의 두 가지 특징이 있다는 점을 강조하는 것이 중요합니다.


프론트 엔드에서 사용자와 서버리스 


정적 사이트와 매우 유사한 하나의 플레이버가 아래 다이어그램에 표시됩니다. 서버 측에서 페이지를 렌더링 해야 하거나 API 경로가 호출 될 때마다 이러한 호출은 서버리스 기능으로 실행됩니다. 이 모델에서 인증은 클라이언트 측에서 수행됩니다.

  1. 사용자가 Auth0으로 리디렉션 됩니다
  2. 사용자가 성공적으로 로그인하면 애플리케이션으로 다시 리디렉션 됩니다.
  3. 클라이언트 측은 Auth0과의 코드 교환을 완료하고 메모리에 저장 될 사용자의 id_token 및 access_token을 검색합니다.

Next.js client-side authentication for the Serverless Deployment model 

서버리스 기능으로 렌더링 된 모든 페이지는 인증 형식이 없어도 모든 사용자가 액세스 할 수 있는 콘텐츠 만 반환 할 수 있습니다. 그런 다음 페이지가 로드 되면 클라이언트 측에서 일부 로직을 실행하여 API 경로를 호출하거나 다른 API를 호출하여 사용자 별 콘텐츠를 가져올 수 있습니다.


Next.js client-side logic in the Serverless Deployment model 


위의 다이어그램에서 이것이 어떻게 작동 하는지에 대한 예를 볼 수 있습니다.

  1. /account 페이지는 서버리스 기능 (SSR)으로 렌더링 할 수 있습니다.
  2. 또한 이 서버리스 기능은 /api/pricing-tiers API 경로를 호출하여 응용 프로그램에서 사용할 수 있는 다양한 구독 유형 (예 : Free, Developer, Enterprise)을 반환합니다. 이것은 공개 정보이므로 인증이 필요하지 않습니다.
  3. 클라이언트 측이 준비되면 이제 /api/billing-info API 경로를 호출하고 사용자의 액세스 토큰을 제공 할 수 있습니다. 그러면 클라이언트 측에서 사용자에게 고유 한 컨텐츠를 렌더링 할 수 있습니다

클라이언트 측 및 API 경로 만 사용자를 인식하는 반면 페이지의 서버 측 렌더링은 공개 컨텐츠만 렌더링 할 수 있었습니다 (이는 SEO 목적으로는 완벽합니다).


백엔드에서 사용자와 서버리스 


이 모델의 두 번째 특징은 서버리스 기능으로 페이지를 렌더링 할 때 사용자가 필요로 하는 특징입니다. 그렇게 되면 클라이언트 측 인증에만 의존 할 수 없습니다


Next.js Serverless Diagram 


이 다이어그램은 미묘하지만 중요한 차이점을 제외하고 프론트 엔드 모델의 다이어그램과 유사합니다.

  1. /account 페이지는 SSR (serverless function)로 렌더링 할 수 있지만 브라우저는 세션 쿠키를 함께 보냅니다.
  2. 이 서버리스 기능은 이제 세션 쿠키를 전달하여 /api/billing-info를 호출하여 서버 측 사용자 컨텐트 렌더링을 가능하게 합니다.
  3. 이 서버리스 함수는 / api/pricing-tiers API 경로도 호출합니다 (여기서는 변경되지 않음).

이 예에서 사용자의 계정 페이지는 서버 측에서 완전히 렌더링 될 수 있습니다.


고려해야 할 사항은 사이트가 이미 완전히 로드 되어 있고 사용자가 계정 페이지로 이동 한 경우입니다. 이 경우 클라이언트 측에서 엔드 포인트를 직접 호출 할 수 있으며 쿠키는 API 경로에 자동으로 제공됩니다.


  1. 클라이언트 측은 인증이 필요한 API 경로를 호출 할 수 있습니다 (세션 쿠키는 브라우저에서 자동으로 제공되므로)
  2. 클라이언트 측도 인증이 필요 없는 API 경로를 호출합니다.

Next.js Serverless API Call Diagram 

이 사용 사례를 수용하기 위해 최근 인증 코드 부여를 사용하여 서버리스 배포 모델에서 인증을 처리하는 @ auth0 / nextjs-auth0의 초기 액세스 버전을 게시했습니다. 이 패키지는 또한 가장 일반적인 XSS 공격을 완화시키는 HttpOnly 쿠키를 사용하여 인증 된 사용자에 대한 세션을 생성합니다.


라이브러리를 사용하려면 먼저 SDK 인스턴스를 초기화하십시오.


import { initAuth0 } from '@auth0/nextjs-auth0';


export default initAuth0({

  domain: '<AUTH0_DOMAIN>',

  clientId: '<AUTH0_CLIENT_ID>',

  clientSecret: '<AUTH0_CLIENT_SECRET>',

  scope: 'openid profile',

  redirectUri: 'http://localhost:3000/api/callback',

  postLogoutRedirectUri: 'http://localhost:3000/',

  session: {

    cookieSecret: 'some-very-very-very-very-very-very-very-very-long-secret',

    cookieLifetime: 60 * 60 * 8

  }

});


인스턴스가 생성되면 Next.js 애플리케이션에 필요한 모든 로직을 처리하는 몇 가지 API 경로를 추가하게 됩니다. 다음은 로그인 핸들러의 예입니다.


import auth0 from '../../utils/auth0';


export default async function login(req, res) {

  try {

    await auth0.handleLogin(req, res);

  } catch(error) {

    res.status(error.status || 500).end(error.message)

  }

}


그리고 그게 다야! 이제 서버 측에서 사용자에게 액세스 할 수 있습니다.


Profile.getInitialProps = async ({ req, res }) => {

  if (typeof window === 'undefined') {

    const { user } = await auth0.getSession(req);

    if (!user) {

      res.writeHead(302, {

        Location: '/api/login'

      });

      res.end();

      return;

    }


    return { user }

  }

}


프로파일 핸들러를 구현하면 사용자 정보를 클라이언트 측에 공개하는 엔드 포인트도 있습니다. 따라서 액세스 토큰이나 그에 대한 걱정 없이 Next.js 애플리케이션 내에서 API 라우트를 호출 할 수 있습니다. 이는 사용자 세션이 쿠키에 저장되어 클라이언트가 API 경로에 대한 모든 요청과 함께 전송되기 때문에 가능합니다.


async componentDidMount() {

  const res = await fetch('/api/me');

  if (res.ok) {

    this.setState({

      session: await res.json()

    })

  }

}


이 모델에서 인증은 서버에서 이루어집니다. 즉, 클라이언트는 사용자가 로그인 한 것을 실제로 인식하지 못합니다. 초기 상태 또는 엔드 포인트를 통해 해당 정보를 제공하여 이를 알 수 있지만 id_token 또는 access_token을 클라이언트에 노출시키지 마십시오. 이 정보는 서버 측에 남아 있습니다.


커튼 뒤에서 정확히 어떻게 됩니까? 


nextjs-auth0을 사용하는 경우 사용자는 인증 코드 부여를 사용하여 로그인합니다. 높은 수준에서 사용자는 Auth0 (1,2)으로 리디렉션 되어 사용자가 인증 및 승인 로직 (가입, 로그인, MFA, 동의 등)을 모두 처리합니다. 쿼리 문자열 (3)의 인증 코드를 사용하여 애플리케이션으로 다시 리디렉션 됩니다.


Authorization Code Exchnage diagram 


서버 측 (또는 서버리스 기능)은 해당 코드를 id_token 및 선택적으로 access_token 및 refresh_token으로 교환합니다 (4). id_token의 유효성이 검사되면 세션이 생성되어 암호화 된 쿠키 (5)에 저장됩니다. 페이지가 렌더링되거나 (서버 측) API 경로가 호출 될 때마다 세션 쿠키가 서버리스 기능으로 전송되어 세션 및 관련 사용자 정보에 액세스 할 수 있습니다.


외부 API 호출 


페이지 및 API 경로는 모두 사용자 세션에 액세스 할 수 있지만 일반적으로 다른 (하위) 도메인에서 호스팅 되는 외부 API의 경우에는 해당되지 않습니다. 해당 API에 액세스 할 때 사용자에게 권한을 부여하려면 access_token을 제공해야 합니다.

사용자 대신 외부 API를 호출해야 하는 경우 Next.js API 경로를 통해 해당 호출을 프록시해야 합니다. 이러한 경로는 사용자의 세션에 액세스 할 수 있으며 사용자가 로그인 한 방법에 따라 해당 세션에 사용자 정보가 포함될 수 있습니다. 선택적으로 세션에는 다음이 있을 수도 있습니다.


  • id_token
  • access_token
  • refresh_token

Identity icons for users, authentication, and API interaction graphicsNext.js API 경로가 사용자 대신 외부 API를 호출해야 하는 경우 세션에서 access_token을 추출하여 Authorization 헤더에 추가 할 수 있습니다.


Next.js external API with access token diagram model 


다음 예제는 세션에서 access_token을 추출한 후이를 사용하여 다운 스트림 API를 호출하는 API 라우트를 작성하는 방법을 보여줍니다.


import auth0 from '../../utils/auth0';


export default async function getBillingInfo(req, res) {

  try {

    const { accessToken } = await auth0.getSession(req);


    const client = new BillingApiClient(accessToken);

    return client.getBillingInfo();

  } catch(error) {

    console.error(error)

    res.status(error.status || 500).end(error.message)

  }

}


프론트 엔드 모델과의 가장 큰 차이점은 서버가 페이지를 렌더링 할 때 로그인 한 사용자를 인식한다는 것입니다. 이러한 서버 측은 공개 데이터 로드로 제한되지 않으므로 사용자 고유의 데이터를 로드하고 해당 정보를 서버 측으로 렌더링 할 수도 있습니다.


전체 Next 예제는 공식 Next.js 저장소에서 찾을 수 있습니다.


커스텀 서버 접근 


Next.js에서 볼 수있는 매우 일반적인 (레거시) 배포 모델은 사용자 지정 서버를 사용하여 Next.js 응용 프로그램을 호스팅 하는 위치입니다. Express.js와 같은 것을 사용하여 구현 될 수 있는 Next.js의 커스텀 서버는 요청을 받아 app.getRequestHandler() 메소드 호출에서 반환 된 요청 핸들러로 전달합니다. 이 접근 방식을 사용하면 사용자 지정 서버가 프록시 역할을 하며 Next.js가 요청을 처리하기 전에 약간의 처리를 수행 할 수 있습니다.


Custom Server Approach Next.js handling request diagramNext.js 서버 측 렌더링 전에 실행되는 미들웨어는 다음과 같이 애플리케이션에 빌딩 블록을 제공합니다.


  • Authentication
  • Sessions
  • Enforcing authentication and authorization
  • Rate limiting

Express.js와 함께 오늘 사용할 수 있는 모든 빌딩 블록과 도구를이 모델에서 사용할 수 있습니다. 다음은 Express.js로 Next.js 응용 프로그램을 호스팅 하는 가장 기본적인 예입니다.


const next = require('next');

const express = require('express');

...


const app = next({ dev });

const handle = app.getRequestHandler();


app.prepare()

  .then(() => {

    const server = express();

    ...

    passport.use(auth0);

    ...

    server.use(passport.initialize());

    server.use(passport.session());

    server.use(myApiRoutes);

    ...

    server.get('*', (req, res) => {

      return handle(req, res);

    });


    server.listen(3000, (err) => {

      if (err) {

        throw err;

      }


      console.log('Listening on http://localhost:3000')

    });

  })

  .catch((ex) => {

    console.error(ex.stack);

    process.exit(1);

  });


이 모델에서 사용자를 인증 할 때는 Passport.js (Passion.auth0)와 함께 Passport.js (Node.js에서 가장 널리 사용되는 인증 프레임 워크 임)를 사용할 수 있습니다. 사용자가 로그인하면 express-session을 사용하여 세션이 생성 된 다음 HttpOnly 쿠키를 사용하여 브라우저에 유지됩니다.


Custom Server model cookie HttpOnly diagram 


사용자에게 세션이 있으면 Next.js API 경로 또는 기존 Express 엔드 포인트를 사용하여 인증이 필요한 페이지에 액세스하거나 API 엔드 포인트를 호출 할 수 있습니다. 세션 쿠키는 각 요청과 함께 전송되어 서버 측에서 사용자 정보를 자동으로 사용할 수 있게 합니다.


Custom Server model server-side exchange diragram 


이 모델에서는 기본적으로 Node.js를 사용하여 일반 웹 애플리케이션을 빌드 합니다. 인증, 데이터베이스 액세스 및 기타 기능은 이미 해결 된 문제입니다.


사용자 정의 서버를 사용하여 Next.js 애플리케이션을 작성하는 전체 예제는 다음에서 찾을 수 있습니다. Next.js 인증 학습서 


레거시 모델? 


Next.js 문서는 이 모델이 비용 및 성능 관점에서 가장 최적이기 때문에 더 이상 나열하지 않습니다.


  • 분산 장애 지점, 무한한 확장 성 및 저렴한 비용과 같은 서버리스 배포 모델의 장점을 놓치고 있습니다.
  • 정적 사이트를 생성 할 수 없습니다. 공개 사이트를 운영하는 경우 원하는 사이트 일 수 있습니다. 정적 사이트는 빠르고 비용이 적게 듭니다


결론 


이를 통해 Next.js 프레임 워크에서 현재 존재하는 다양한 배포 모델을 다루었으며 해당 모델에서 인증하는 가장 좋은 방법과 그 이유를 설명했습니다.


이 학습서가 배치 모델에 사용할 것을 더 잘 결정하는 데 도움이 되었으면 아래 의견에 알려주십시오!


Auth0 정보 


애플리케이션 빌더를 위한 아이덴티티 플랫폼 인 Auth0은 모든 시장 부문에서 수천 명의 고객에게 웹, 모바일, IoT 및 내부 애플리케이션에 필요한 유일한 아이덴티티 솔루션을 제공합니다. 확장 가능한 플랫폼은 매월 25 억 회 이상의 로그인을 원활하게 인증하고 보호하여 개발자들에게 사랑 받고 있으며 글로벌 기업들에게 신뢰 받고 있습니다. WA 벨뷰에 본사를 둔 미국 본사와 런던, 도쿄, 시드니 부에노스 아이레스에 있는 추가 사무소는 70 개국 이상에 위치한 글로벌 고객을 지원합니다.