[아이덴티티 및 접근 관리(IAM)](https://auth.wiki/iam)의 영역은 최근 몇 년간 더 복잡해졌습니다. [OAuth](https://auth.wiki/oauth), [OpenID Connect (OIDC)](https://auth.wiki/openid-connect), [SAML](https://auth.wiki/saml), [SSO](https://auth.wiki/single-sign-on), 그리고 [JWT](https://auth.wiki/jwt) 같은 복잡한 용어가 자주 사용됩니다. 하지만 그것들은 무엇을 의미하나요? 그것들은 어떻게 함께 작동하나요? 이 개념과 프레임워크를 탐색해 이해하기 쉽고 실용적으로 만들어 보겠습니다. 각 프로토콜과 프레임워크는 더 깊이 탐구할 수 있습니다. 이 기사는 기본적인 이해를 제공하는 것을 목표로 합니다. 각 주제에 대한 자세한 통찰력은 [Auth Wiki](https://auth.wiki)를 방문하세요. ## IAM이란? 아이덴티티 및 접근 관리(IAM)는 디지털 **아이덴티티**를 관리하고 **접근 제어**를 구현하는 광범위한 개념입니다. 앞서 언급된 프레임워크와 프로토콜은 IAM에 속하며, 각각 이 분야의 특정 문제를 해결합니다. 본질적으로 IAM은 다음을 다룹니다: - **아이덴티티**: 사용자, 서비스 또는 장치의 디지털 표현. 아이덴티티는 일반적으로 이름, 이메일, 역할 등과 같은 속성을 포함하여 엔티티를 설명합니다. - **접근**: 자원과 상호작용하거나, 행동을 수행하거나, 서비스를 사용하는 능력. 접근은 어떤 행동이 어떤 자원에서 수행될 수 있는지를 정의합니다. ```mermaid graph LR subgraph User Name Email Role end API User -->|GET| API ``` 위 다이어그램에서 사용자는(API)에게 `GET` 요청(자원)을 수행하고 싶어 하는 사용자(아이덴티티)입니다. 사용자의 속성인 이름, 이메일, 역할은 아이덴티티를 설명합니다. ### 인증과 권한 인증과 권한은 IAM 논의에서 흔히 같이 나타납니다. 그들의 정의를 명확히 해봅시다: - **인증**: 소유하고 있는 아이덴티티를 검증하는 과정입니다. 그것은 "어떤 아이덴티티를 소유하나요?"라는 질문에 답합니다. - **권한**: 인증된 아이덴티티가 자원에 대해 수행할 수 있는 행동을 결정하는 과정입니다. 그것은 "무엇을 할 수 있나요?"라는 질문에 답합니다. 권한은 접근 제어의 부분집합입니다. 접근 제어는 권한 및 기타 제한을 포함하는 더 넓은 개념입니다. 자세한 내용은 [접근 제어](https://auth.wiki/access-control)를 참조하세요. 앞서의 예에서: - 사용자가(아이덴티티) 어떤 행동을 수행하기 전에, 그들은 **인증** 과정을 완료해야 합니다. - 인증 후, 시스템은 사용자가 API(자원)에 대해 `GET` 요청(행동)을 수행할 수 있는지 여부를 결정해야 하며, 즉, **권한** 부여 과정을 완료해야 합니다. --- 이 기본 지식으로 무장하여, 다른 약어와 프로토콜을 이해해 봅시다. ## OAuth [OAuth 2.0](https://auth.wiki/oauth-2.0), 일반적으로 OAuth로 불리며, 애플리케이션이 다른 애플리케이션에서 보호된 자원에 접근할 수 있도록 해주는 **권한** 프레임워크입니다(주로 사용자를 대신하여). 예를 들어, *MyApp*이라는 웹 애플리케이션이 사용자의 Google Drive에 접근하려 한다고 가정해 보세요. 사용자의 Google Drive 자격 증명을 공유하도록 요청하는 대신, *MyApp*은 OAuth 2.0을 사용하여 Google에 사용자의 Drive에 접근할 수 있도록 권한(**authorization**)을 요청할 수 있습니다. 다음은 OAuth 흐름을 간단하게 설명한 다이어그램입니다: ```mermaid sequenceDiagram autonumber actor User participant MyApp participant Google User->>MyApp: MyApp 열고
"Google Drive 연결" 클릭 MyApp->>Google: 권한 요청과 함께 Google로 리디렉션 Google->>User: Google 로그인 프롬프트 User->>Google: 로그인 Google->>User: Google Drive에
접근할 권한 요청 User->>Google: MyApp에 접근 권한 부여 Google->>MyApp: 접근 토큰과 함께
MyApp으로 리디렉션 MyApp->>Google: 접근 토큰을 사용하여
Google Drive에 접근 ``` 이 흐름에서: - *MyApp*은 Google Drive(자원)에 접근을 요청하는 클라이언트(아이덴티티)입니다. - 단계 6에서 사용자가 *MyApp*에 인증을 완료하면서 **권한** 부여 프로세스를 완료합니다. OAuth 2.0은 사용자가 Google에게 어떻게 인증하는지(3단계와 4단계)에 대해 정의하지 않습니다. 이 부분은 Google의 구현에 맡겨져 있습니다. OAuth 2.0의 핵심 요소는 **액세스 토큰**입니다. 이 토큰은 클라이언트가 자원에 접근할 사용자의 권한을 입증하는 데 사용합니다. 더 깊이 알아보고 싶다면 [Access token](https://auth.wiki/access-token)을 참조하세요. ## OpenID Connect (OIDC) [OpenID Connect (OIDC)](https://auth.wiki/openid-connect)는 OAuth 2.0 위에 구축된 **인증** 계층으로, 인증을 위해 [ID 토큰](https://auth.wiki/id-token) 및 [UserInfo 엔드포인트](https://auth.wiki/userinfo-endpoint)와 같은 기능을 추가하여 인증과 권한 부여 모두에 적합합니다. OAuth 흐름을 다시 방문하면, OIDC를 추가하면 **ID 토큰**이 도입됩니다. 이 토큰은 인증된 사용자에 대한 정보를 포함하고, MyApp에서 사용자의 아이덴티티를 확인하는 데 사용됩니다. ### 예시 시나리오: "Google로 로그인" 예제를 바꿔 봅시다. MyApp이 사용자가 Google 계정을 사용해 로그인할 수 있도록 허용하려 한다면 목표가 리소스 접근보다 인증으로 바뀝니다. 이 경우 OIDC가 더 나은 선택입니다. OIDC 흐름은 다음과 같습니다: ```mermaid sequenceDiagram autonumber actor User participant MyApp participant Google User->>MyApp: "Google로 로그인" 클릭 MyApp->>Google: 인증 요청과 함께 리디렉션 Google->>User: Google 로그인 프롬프트 User->>Google: 로그인 Google->>User: 사용자 정보
공유 권한 요청 User->>Google: 권한 부여 Google->>MyApp: ID 및 액세스 토큰과 함께
MyApp으로 리디렉션 MyApp->>MyApp: ID 토큰에서 사용자
정보 확인 및 추출 ``` **주요 차이점**: 액세스 토큰 외에도, OIDC는 **ID 토큰**을 제공합니다. 이를 통해 MyApp은 사용자 인증을 추가적인 요청 없이 수행할 수 있습니다. OIDC는 OAuth 2.0의 [grant](https://auth.wiki/oauth-2.0-grant) 정의를 공유하여 두 프레임워크 간의 호환성과 일관성을 보장합니다. ## SAML [Security Assertion Markup Language (SAML)](https://auth.wiki/saml)은 XML 기반의 프레임워크로, 당사자 간 **인증** 및 **권한 부여** 데이터를 교환합니다. SAML은 2000년대 초에 도입되어 기업 환경에서 널리 채택되었습니다. ### SAML은 OIDC와 어떻게 비교되나요? SAML과 OIDC는 기능적으로 유사하지만 구현 세부 사항에서 차이가 있습니다: - **SAML**: XML 기반 어설션을 사용하며, 더 복잡하다고 여겨집니다. - **OIDC**: JSON과 JWT를 활용하여 더 가볍고 개발자 친화적입니다. 현대 애플리케이션은 OIDC를 선호하는 경우가 많지만, SAML은 여전히 레거시 시스템과 기업용 애플리케이션에서 널리 사용됩니다. ## Single sign-on (SSO) [Single sign-on (SSO)](https://auth.wiki/sso)는 사용자가 한 세트의 자격 증명으로 여러 애플리케이션과 서비스를 이용할 수 있도록 하는 **인증** 방식입니다. 각각의 애플리케이션에 개별적으로 로그인하는 대신, 사용자는 한 번 로그인하여 모든 연결된 시스템에 접근할 수 있습니다. ### SSO는 어떻게 작동하나요? SSO는 사용자 아이덴티티를 관리하는 중앙 [아이덴티티 제공자(IdP)](https://auth.wiki/identity-provider)에 의존합니다. IdP는 사용자를 인증하고 연결된 애플리케이션에 인증 및 권한 부여 서비스를 제공합니다. ```mermaid graph LR User --> AppA User --> AppB AppA <--> IdP[아이덴티티 제공자] AppB <--> IdP User -->|SSO| IdP ``` IdP는 OIDC, OAuth 2.0, SAML 또는 기타 프로토콜을 사용하여 이러한 서비스를 제공합니다. 단일 IdP는 다양한 애플리케이션의 다양한 요구를 충족시키기 위해 여러 프로토콜을 지원할 수 있습니다. #### OIDC 기반 SSO의 예 OIDC 기반 SSO의 예시를 살펴보겠습니다: ```mermaid sequenceDiagram actor User participant AppA participant AppB participant IdP User->>AppA: 애플리케이션 A 접근 AppA->>IdP: IdP로 리디렉션 IdP->>User: 자격 증명 입력 요청 User->>IdP: 자격 증명 제공 IdP->>AppA: ID 토큰 전송 AppA->>User: 접근 승인 User->>AppB: 애플리케이션 B 접근 AppB->>IdP: IdP로 리디렉션 IdP->>IdP: 사용자가 이미 인증됨 IdP->>AppB: ID 토큰 전송 AppB->>User: 접근 승인 ``` 이 흐름에서 사용자는 IdP에 한 번 로그인하고 여러 애플리케이션(AppA와 AppB)에서 인증됩니다. ### 기업 SSO SSO는 광범위한 개념이지만, [기업 SSO](https://auth.wiki/enterprise-sso)라는 용어도 볼 수 있으며, 이는 기업 환경(일반적으로 직원 및 파트너용)용으로 설계된 특정 유형의 SSO를 의미합니다. 고객이 애플리케이션에 대한 SSO를 요청할 때, 그들의 요구와 사용 중인 프로토콜을 명확히 하는 것이 중요합니다. 대부분의 경우, 이는 특정 이메일 도메인에 대해 애플리케이션이 인증을 위해 그들의 IdP(기업 SSO를 구현하는)로 사용자를 리디렉션하기를 원한다는 것을 의미합니다. #### 기업 SSO 제공자 추가 예시 애플리케이션(MyApp)에 기업 SSO 제공자(Banana)를 통합하는 간단한 예시입니다: ```mermaid sequenceDiagram actor User participant MyApp participant IdP as MyApp IdP participant Banana as Banana IdP User->>MyApp: "로그인" 클릭 MyApp->>IdP: IdP로 리디렉션 IdP->>User: 자격 증명 입력 요청 User->>IdP: Banana 이메일 제공 IdP->>Banana: Banana IdP로 리디렉션 Banana->>User: 자격 증명 입력 요청 User->>Banana: 자격 증명 제공 Banana->>IdP: 응답 전송 IdP->>MyApp: 응답 전송 MyApp->>User: MyApp에 접근 승인 및 사용자 정보 표시 ``` IdP로 리디렉션하는 것은 SSO 흐름에서 일반적인 패턴입니다. 이 접근은 IdP가 사용자 세션에 대해 중앙 집중화를 유지하면서 여러 애플리케이션에 인증 및 권한 부여 서비스를 제공할 수 있도록 합니다. ## JWT [JSON Web Token (JWT)](https://auth.wiki/jwt)은 RFC 7519에 정의된 개방형 표준으로 두 당사자 간의 안전한 통신을 가능하게 합니다. 이는 OIDC의 ID 토큰의 표준 형식이며 OAuth 2.0 액세스 토큰으로 널리 사용됩니다. 다음은 JWT의 주요 특징입니다: - **간결함**: JWT는 쉽게 전송하고 저장할 수 있는 간결한 형식으로 인코딩된 JSON 객체입니다. - **자체 포함**: JWT는 사용자와 토큰 자체에 대한 모든 필요한 정보를 포함하고 있습니다. - **검증 및 암호화 가능**: JWT는 데이터 무결성과 기밀성을 보장하기 위해 서명되고 암호화될 수 있습니다. 일반적인 JWT는 다음과 같습니다: ``` eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiJmb28iLCJuYW1lIjoiSm9obiBEb2UifQ.XM-XSs2Lmp76IcTQ7tVdFcZzN4W_WcoKMNANp925Q9g ``` 이 JWT는 점으로 구분된 세 부분으로 구성됩니다: ``` {{header}}.{{payload}}.{{signature}} ``` - **헤더**: 토큰 유형과 서명 알고리즘과 같은 메타데이터를 포함합니다. - **페이로드**: 아이덴티티와 토큰 자체에 대한 정보를 포함합니다. - **서명**: 토큰의 무결성을 검증합니다. 헤더와 페이로드 모두 base64로 인코딩된 JSON 객체입니다. 위 JWT는 다음과 같이 디코딩할 수 있습니다: ```jsonc // 헤더 { "alg": "HS256", "typ": "JWT" } // 페이로드 { "sub": "foo", "name": "John Doe" } ``` JWT를 사용하여 클라이언트는 아이덴티티 제공자에게 추가 요청을 하지 않고 토큰을 디코딩하고 사용자의 정보를 추출할 수 있습니다. JWT에 대해 자세히 알아보려면 [JSON Web Token (JWT)](https://auth.wiki/jwt)를 방문하세요. ## 요약 이 기사를 통해 많은 것을 다뤘습니다. 주요 포인트를 예제로 요약해 보겠습니다: 웹 애플리케이션 AppA에 **아이덴티티 및 접근 관리(IAM)** 솔루션이 필요하다고 가정해 보세요. 인증을 위해 **OpenID Connect (OIDC)**를 사용하는 **Logto**라는 아이덴티티 제공자를 선택합니다. OIDC는 **OAuth 2.0** 위에 구축되었기 때문에 Logto는 애플리케이션에 대한 권한 부여도 지원합니다. 사용자에게 더 나은 경험을 제공하기 위해 Logto에서 "Google로 로그인" 기능을 활성화합니다. 이는 Logto와 Google 간의 권한 부여 데이터 및 사용자 정보를 교환하기 위해 **OAuth 2.0**을 사용합니다. 사용자는 Logto를 통해 AppA에 로그인 한 후, 사용자 정보가 포함된 **JSON Web Token (JWT)** ID 토큰을 받게 됩니다. 비즈니스가 성장하면서 애플리케이션 AppB를 새로 출시하고 사용자 인증이 필요하게 됩니다. Logto가 이미 설정되어 있으므로 AppB에 동일한 인증 흐름을 재사용할 수 있습니다. 사용자는 이제 단일 자격 증명 세트를 사용하여 AppA와 AppB에 로그인할 수 있으며, 이를 **단일 로그인(SSO)** 기능이라 부릅니다. 이후, 비즈니스 파트너가 그들의 기업 SSO 시스템을 연결하라고 요청합니다. 이는 **Security Assertion Markup Language (SAML)**을 사용합니다. Logto가 SAML 연결을 지원하는 것을 발견하여 Logto와 파트너의 SSO 시스템 간의 연결을 설정합니다. 이제 파트너 조직의 사용자들도 기존 자격 증명을 사용해 AppA와 AppB에 로그인할 수 있습니다. --- 이 기사가 이러한 개념을 명확히 이해하는 데 도움이 되었기를 바랍니다. 더 심도 깊은 설명과 예제를 보려면 [Auth Wiki](https://auth.wiki)를 확인해 보세요. 애플리케이션을 위한 IAM 솔루션을 찾고 있다면, 시간을 절약하고 노력을 덜 수 있는 [Logto](https://logto.io)와 같은 관리 서비스 사용을 고려해 보세요.