Auth0

ding·2024년 9월 27일

M2M(Machine to Machine)

M2M 애플리케이션은 두 시스템(애플리케이션 또는 서비스) 간에 사용자 상호작용 없이 안전하게 통신해야 할 때 사용된다. 사용자가 인증을 위해 시스템과 상호작용할 필요가 없으며 시스템이 클라이언트를 인증하고 승인해야 한다.

사용 사례

  • 서버 간 통신
  • 사용자 참여가 없는 애플리케이션
  • IoT

  1. client는 authorization server에 client Id, client secret 등의 정보를 보내며 request한다.
POST https://<YOUR_AUTH0_DOMAIN>/oauth/token
Content-Type: application/json
{
  "audience": "<API_IDENTIFIER>",
  "grant_type": "client_credentials",
  "client_id": "<YOUR_CLIENT_ID>",
  "client_secret": "<YOUR_CLIENT_SECRET>"
}
  1. authorization server는 request에 대한 response로 access token을 보낸다.
HTTP/1.1 200 OK
Content-Type: application/json
{
  "access_token": "eyJz93a...k4laUWw",
  "token_type": "Bearer",
  "expires_in": 86400
}
  1. client는 access token을 사용하여 resource server(API)에 request를 보낼 수 있다.

사용 방법

  1. Auth0에서 M2M 애플리케이션을 생성한다.
  2. 백엔드 서비스가 인증할 수 있도록 클라이언트 자격 증명(클라이언트 ID 및 비밀키)을 제공한다.
  3. 인증이 성공하면 Auth0는 Access Token을 발급하며, 이를 통해 애플리케이션이 API에 권한 있는 호출을 할 수 있게 된다.

SPA(Single Page Application)

SPA는 전체 페이지 리로드 없이 브라우저에서 전적으로 실행되는 웹 애플리케이션에 사용된다.

사용 사례

  • React, Angular, Vue.js와 같은 프론트엔드 프레임워크로 빌드된 애플리케이션
  • 사용자 인터페이스가 서버 측 페이지 로드 없이 동적으로 업데이트되는 경우

사용 방법

  1. Auth0에서 SPA 애플리케이션을 생성한다.
  2. @auth0/auth0-react 같은 라이브러리를 사용하여 SPA에서 인증 플로우를 처리한다.
import { Auth0Provider } from '@auth0/auth0-react';

const App = () => (
  <Auth0Provider
    domain="{yourDomain}"  // Auth0 대시보드에서 제공되는 도메인
    clientId="{yourClientId}"  // Auth0 대시보드에서 제공되는 클라이언트 ID
    redirectUri={window.location.origin}  // 인증 성공 시 사용자를 리다이렉트할 URI
  >
    <YourApp />
  </Auth0Provider>
);
  1. SPA는 리다이렉트 기반 플로우나 PKCE(Proof Key for Code Exchange)와 같은 OAuth2 프로토콜을 사용하여 보안 로그인을 처리하고 토큰을 관리한다.

Auth0 Dashboard

Auth0 대시보드를 통해 인증 플로우를 광범위하게 사용자 지정할 수 있다.

사용자 역할과 권한 관리

Auth0의 User Management > Roles에서 사용자의 기능이나 접근 수준에 따라 권한을 부여하고 조직화할 수 있다.

사용자 구분
“Admin”, “Editor”, “Viewer”와 같은 역할로 사용자를 구분할 수 있으며, 각 역할은 애플리케이션의 다른 부분에 대한 접근 수준을 정의하는 데 사용된다.

조직

Auth0의 Organizations는 멀티 테넌트 환경을 지원하며, 서로 다른 회사 또는 그룹의 사용자가 로그인하고 각각 다른 역할이나 권한을 가질 수 있다.

조직을 나누는 이유

  • 각 테넌트 또는 조직별로 사용자 기반을 분리할 수 있다.
  • 조직별로 역할 및 권한을 관리할 수 있다.
  • 각 조직에 맞춘 로그인 경험(브랜딩, 리다이렉트) 제공할 수 있다.

// @auth/auth0-react : SPA Library
// 로그인/로그아웃 & 사용자 정보 및 인증 상태 확인

import React from 'react';
import Link from 'next/link';
import { useAuth0 } from '@auth0/auth0-react';
import { useRouter } from 'next/router';
import { Loading } from './Loading';

export function Nav() {
  const { isAuthenticated, isLoading, user, loginWithRedirect, logout } =
    useAuth0();
  const { pathname } = useRouter();

  // isLoading: 인증 프로세스가 진행 중인지 여부
  if (isLoading) {
    return <Loading />;
  }

  return (
    <nav className="navbar navbar-expand-lg navbar-light bg-light">
      // isAuthenticated: 사용자가 인증된 상태인지 확인
      {isAuthenticated ? (
        <div>
          // user: 로그인된 사용자의 프로필 정보 포함
          <span id="hello">Hello, {user.name}!</span>{' '}
          // logout: 로그아웃 시 사용자를 특정 URL로 리다이렉트하여 인증 상태를 초기화함
          <button
            className="btn btn-outline-secondary"
            id="logout"
            onClick={() =>
              logout({ logoutParams: { returnTo: window.location.origin } })
            }
          >
            logout
          </button>
        </div>
      ) : (
        // loginWithRedirect: 사용자가 Auth0의 로그인 페이지로 리다이렉트되고, 로그인 성공 후 애플리케이션으로 다시 리다이렉트됨
        <button
          className="btn btn-outline-success"
          id="login"
          onClick={() => loginWithRedirect()}
        >
          login
        </button>
      )}
    </nav>
  );
}

ID Token VS Access Token

ID Token

인증된 사용자를 나타내며, 사용자 프로필 정보(이메일, 이름 등)를 포함한다.
ID Token은 사용자의 신원을 확인하는 목적으로만 사용해야 하며, 권한 부여와는 직접적인 관련이 없다.

ID Token은 JWT로 인코딩된다.

ID Token 예(JWT)

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJodHRwOi8vbXktZG9tYWluLmF1dGgwLmNvbSIsInN1YiI6ImF1dGgwfDEyMzQ1NiIsImF1ZCI6IjEyMzRhYmNkZWYiLCJleHAiOjEzMTEyODE5NzAsImlhdCI6MTMxMTI4MDk3MCwibmFtZSI6IkphbmUgRG9lIiwiZ2l2ZW5fbmFtZSI6IkphbmUiLCJmYW1pbHlfbmFtZSI6IkRvZSJ9.bql-jxlG9B_bielkqOnjTY9Di9FillFb6IMQINXoYsw

decoding 결과 : 사용자와 토큰 자체에 대한 선언(claims)

{ 
  "iss": "http://my-domain.auth0.com", // 토큰을 발급한 인증 서버
  "sub": "auth0|123456", // 고유 사용자 식별자
  "aud": "1234abcdef", // 토큰이 발급된 대상(클라이언트 애플리케이션)
  "exp": 1311281970, // 토큰 만료 시간
  "iat": 1311280970, 
  "name": "Jane Doe", // 사용자 이름 
  "given_name": "Jane", 
  "family_name": "Doe"
}

Access Token

API 접근 권한을 부여하는 토큰으로, 사용자가 접근할 수 있는 리소스에 대한 정보를 포함한다.
Access Token을 API에 전달하여 접근 권한을 증명해야 한다.

Access Token은 JWT형식 또는 일반 토큰(opaque token)으로 발급될 수 있다.

특징ID TokenAccess Token
목적사용자의 신원 확인API 또는 리소스에 대한 접근 권한 부여
발급 프로토콜OIDCOAuth2.0
포함 정보사용자 정보API 접근 권한
주요 사용처클라이언트 애플리케이션(사용자 프로필 확인)서버나 API에 전달되어 인증된 요청으로 사용
형식JWTJWT 또는 opaque token
유효성 검증 대상클라이언트 애플리케이션이 토큰의 유효성을 검증API가 토큰의 유효성을 검증
수명상대적으로 짧은 수명(몇 분에서 몇 시간)API 접근에 필요한 만큼 유효(짧게 설정, 갱신 가능)
사용 범위인증된 사용자 정보만 제공보호된 리소스나 API에 접근 권한을 부여
API 호출 사용API에 사용되지 않음API 호출 시 반드시 필요

M2M에서의 토큰

  • Access Token만 사용 (d/t 서버 간 통신)
  • Access Token이 API 호출을 인증하고, 각 애플리케이션이 적절한 권한을 가지고 있는지 확인하는데 사용한다.

SPA에서의 토큰

  • ID token과 Access Token 둘 다 사용한다.
  • 사용자가 로그인하고 자신의 정보를 확인하기 위해 ID Token을 사용하고, 백엔드 API 요청을 보낼 때에는 Access Token을 사용한다.

0개의 댓글