OpenID Connect 와 Auth2.0

OpenID란?

사용자가 하나의 ID로 여러사이트에 로그인할 수 있게 해주는 인증 프로토콜이다. 사용자는 OpenID 제공자의 계정을 통해 여러 웹 사이트에 로그인이 가능하기 때문에 각 여러 웹사이트에 각각 회원가입을 할 필요가 없다.

 

OpenID 는 다음과 같은 변화가 있었고 현대는 OpenID Connect 세대이다.

 

• 2006년 OpenID 1.0 출시
• 2007년 OpenID 2.0 출시
• 2014년 OpenID Connect 출시

 

OpenID 활용

OpenID는 이미 널리 사용되고 있다. 쇼핑몰에 로그인하거나 어떠한 애플리케이션 앱에 로그인할때 사용하는 SNS 로그인이 대표적인 그 예이다.

 

• SNS 로그인 : Google, FaceBook 등과 같은 소셜 미디어 계정으로 다른 웹사이트에 로그인할 수 있게한다.
• SSO : 기업 내부 시스템에서 다양한 어플리케이션에 접근할때 하나의 인증으로 여러 서비스를 로그인할 수 있게 한다.
  • SSO(Single Sign-On)는 사용자가 여러 애플리케이션이나 서비스에 접근할 때, 단일 로그인 절차로 모든 시스템에 접근할 수 있도록 하는 인증 프로세스이다. 즉 사용자가 한 번 로그인하면 같은 세션 동안 다른 애플리케이션에서도 추가 로그인 없이 접근이 가능하다.
  • SSO 는 주로 한 조직이나 도메인 내의 여러 어플리케이션에 대해서 사용된다.
  • SSO는 SAML(Security Assertion Markup Language), Oauth, Kerberos 등 여러가지 인증 프로토콜을 사용하여 내부 또는 외부 시스템에서 단일 일증을 제공한다.
• OpenID는 QR과 같이 사용되어 사용자가 웹사이트에 로그인할 때 모바일 디바이스로 QR 코드를 스캔하여 OpenID 제공자에서 인증을 받을 수 있다.
• 모바일에서는 OpenID는 생체인식, OTP 등과 결합하여 보안을 강화할 수 있다.

 

OpenID와 SSO

OpenID와 SSO를 비교해보자.

 

	OpenID	SSO
목적	여러 웹사이트 간 통합 로그인	같은 도메인/조직 내 여러 애플리케이션 간 단일 로그인
사용 환경	외부 웹사이트 간	내부 애플리케이션 간 또는 클라우드 서비스에서
인증 방식	사용자 중심, 외부 제공자가 인증을 관리	중앙 관리 서버가 세션을 관리
보안	비밀번호 분산을 방지하여 보안 강화	계정 해킹 시 여러 애플리케이션에 동시 접근 위험 존재
프로토콜	OpenID, OpenID Connect(OAuth 2.0 기반)	SAML, OAuth, Kerberos 등

 

 

결론적으로, OpenID는 주로 서로 다른 웹사이트 간의 인증을 위해 설계된 반면, SSO는 한 도메인이나 조직 내의 여러 애플리케이션에 쉽게 접근할 수 있게 하기 위한 인증 시스템입니다. OpenID는 넓은 범위의 웹 애플리케이션 간 인증을, SSO는 한 시스템 내에서 사용자 경험을 간소화하는 데 중점을 둡니다.

 

 

OpenID Connect (OIDC)

OpenID Connect는 OpenID의 차세대 버전으로 OAuth 2.0(IETF RFC 6749 및 6750)을 기반으로한 인증 프로토콜이다.

 

OpenID Connect는 인증서버에서 수행한 인증을 바탕으로 사용자의 신원을 확인(사용자 인증)하고 사용자 프로필 정보를 안전하고 쉽게 교환하게 해준다. 이를 통해 사용자는 한번의 로그인으로 (ID 토큰을 사용) 다양한 웹사이트와 애플리케이션에 안전하게 로그인이 가능하다.

뿐만 아니라 ID 데이터 암호화, OpenID 제공자검색, 세션 로그아웃과 같은 추가 기능도 확장 가능하다.

 

개발자에게 이 프로토콜의 가장 큰 장점은 자격 증명 기반의 데이터 유출과 자주 관련되는 비밀번호 설정, 저장, 관리의 책임을 덜어준다는 것이다.

 

OpenID Connect 주요개념

1. OAuth 2.0 기반

OpenID Connect는 OAuth 2.0을 확장한 프로토콜이다.

OAuth 2.0은 주로 인가-권한 부여(authorization)를 다루는 반면, OpenID Connect는 인증(authentication)을 처리하여 사용자의 신원을 검증하는 데 중점을 둔다.

 

사용자는 OpenID 제공자를 통해 A라는 애플리케이션에 별도로 회원가입을 하지 않고 로그인을 할 수 있기 때문에 OpenID 제공자와 애플리케이션 사이에는 사용자를 인증할 수 있는 증명정보에 대한 통신이 이루어져야 한다.

즉 애플리케이션은 사용자의 리소스를 리소스 서버로부터 가져와야하는데 이때 OAuth 2.0가 사용되는 것이다.

 

OAuth 2.0은 애플리케이션이 리소스 소유자(Resource Owner)로부터 리소스 서버의 자원에 대해 인가받고, 접근하기 위해 사용되는데 애플리케이션을 승인한 사용자에 대한 정보를 명시적으로 제공하지 않고 엑세스 토큰형태로 권한을 제공한다. 즉, **OAuth의 주요 목적은 인가(Authorization)**이다. 인가의 과정에서 부산물로써 인증이 존재하긴 하지만, 핵심 목적은 인증이 아니다.

 

2. Client (RP, Relying Party)

웹/앱 애플리케이션 또는 웹사이트로, 사용자를 대신해 OpenID 제공자에게 인증 요청을 보낸다. 클라이언트는 OpenID 제공자에등록되어 있어야 한다.

 

 

3. OpenID 제공자 (OP-OpenID Provider 또는 IDP- Identity Provider)

OpenID 제공자는 OpenId Connect와 OAuth 2.0 프로토콜을 구현한 주체로 인증을 수행하고 ID 토큰을 발급하는 서버이다.

Google, Facebook 같은 대형 서비스가 대표적인 OpenID 제공자로 활동하고 있다.

예를 들어 사용자가 A애플리케이션에 로그인하기 위해서 별도 회원가입을 하지 않고 바로 로그인할 수 있도록 사용자의 신원을 인증해주는 것이 OP의 역할이다.

• Google : Google 계정을 통해 OpenID로 다양한 웹사이트에 로그인이 가능. Google은 OAuth 2.0기반의 인증을 지원하며 OpenID Connect 라는 프로토콜을 통해 사용된다.
• Facebook : Facebook의 로그인 시스템도 OAuth2.0 기반으로 하고 있다.
• Microsoft : Microsoft 계정을 통해 OpenID를 사용하여 다양한 Microsoft 제품에 로그인이 가능하다.

 

4. ID Token

OpenID Connect는 ID 토큰을 발급하여 사용자의 인증 상태와 프로필 정보를 제공한다. 이 토큰에는 사용자의 신원(이름, 이메일 등)과 로그인 세션 정보가 포함된다. 이 토큰은 JWT(JSON Web Token) 형식으로, 안전하고 표준화된 방식으로 정보를 전달한다.

• iss(Issuer) : ID Token를 발급한 OpenID 제공자 정보
• sub(Subject) : 사용자 고유 식별정보. OpenID 제공자 내에서 각 사용자를 구별하기 위한 값
• aud(Audience) : 토큰을 발급받은 Client
• exp(Expiration Time) : 토큰의 만료시간
• iat(Issued At) : 토큰이 발급된 시간
• nonce : Client가 요청에 포함시킨 임의의 문자열. replay 공격을 방지하는데 사용. 요청과 응답에서 이 값이 일치해야한다.
• azp(Authorized Party) : Client가 여러개일 경우 토큰을 발급받은 Client
• at_hash(Access Token Hash) : AccessToken 의 해시 값.

 

5. 사용자

웹사이트나 어플리케이션을 사용하는 사용자이다.

 

 

OpenID Connect의 동작 Flow

 

sequenceDiagram
    participant User as 사용자
    participant SP as Client
    participant OP as OpenID 제공자
    participant Resource as 보호된리소스(API/서비스)
    
    User->>SP: 로그인 시도
    SP->>User: OpenID 제공자 선택 요청
    User->>SP: 선택한 OpenID 제공자 정보 전송
    SP->>OP: 인증요청(로그인 페이지로 리디렉션)
    User->>OP: OpenID 제공자 로그인(아이디, 비밀번호 등)
    OP->>OP: 사용자 인증(2단계 인증 등)
    OP->>User: 권한부여 요청
    User->>OP: 권한부여 
    OP->>SP: ID Token, AccessToken 발급 
    SP->>SP: ID Token 검증(사용자 신원 확인)
    SP->>User: 로그인완료, 서비스 접근 허용 
    SP->>Resource: AccessToken 사용하여 API 요청
    Resource->>SP: 사용자 정보 전달

 

 

OpenID Connect를 왜 사용할까?

OpenId Connect는 사용하기 쉽고 신뢰할 수 있으며 안전한 인증방법을 제공한다. 따라서 개발자가 직접 사용자의 비밀번호를 저장하고 관리할 필요가 없다.

 

OpenID Connect와 OAuth 2.0의 관련성

OAuth 2.0은 Resource Server로부터 리소스를 가져오기 위한 AccessToken을 확보하는데 목적이 있고 OpenID Connect는 사용자의 신원 정보가 담긴 ID Token을 확보하는데 목적이 있다.

• OAuth 2.0 :
  • IETF 에서 2012년에 RFC 6749와 6750으로 명시된 프레임워크이다. 인증 및 권한 부여 프로토콜 개발을 지원하게 위해 설계되었으며 주로 권한 부여(authorization)에 중점을 두고, 리소스 소유자가 특정 리소스에 접근할 수 있는 권한을 부여하는 시스템이다. 사용자는 자신의 자격 증명을 사용해 다른 애플리케이션이 보호된 리소스에 접근하도록 권한을 부여한다.
  • 이 과정에서 인증 서버를 통해 사용자를 인증하는 과정을 거친다. 사용자의 신원 정보가 필요하면, OAuth 2.0 인가 프로세스를 거쳐 발급된 액세스 토큰을 가지고 사용자 정보 리소스에 접근하면 될 것 이다. OIDC없이 사용자 프로필 정보를 리소스 서버로부터 가져올 수 있지만 OIDC 없이 OAuth 2.0 단독으로 사용자 리소스를 가지고 오기 위해서는 OIDC를 사용할 때의 2배의 통신을 해야한다. OAuth 2.0을 단독으로 사용하면, Access Token을 발급 받은 다음 이 토큰을 사용하여 사용자 리소스를 다시 요청하여 받아와야한다. 하지만 OIDC를 사용하면 Access Token과 함께 전달받은 ID Token을 복호화하여 사용자 정보를 가져오면 된다.
• OpenID Connect: OAuth 2.0을 확장하여 사용자 인증(authentication)을 처리하여 신원확인서비스를 제공한다. 사용자의 신원을 증명하고 이를 통해 신뢰할 수 있는 정보를 제공하는 데 중점을 둔다.

 

 

부가내용

OpenID Connect와 OpenID 2.0의 다른점은?

두 프로토콜은 구조적으로 유사하지만 OpenID 2.0은 XML과 맞춤형 메시지 서명방식을 사용했는데 이는 개발자가 구현하기 어려워 상호 운용성을 방해하는 문제가 있었다.

OpenID Connect의 기반인 OAuth 2.0은 필요한 암호화를 웹의 내장된 TLS(HTTPS 또는 SSL) 인프라에 맡기며 서명이 필요할때 JWT 데이터 구조를 사용하기 때문에 개발자가 더 쉽게 구현할 수 있고 상호 운용성도 크게 향상되었다.

OpenID Connect와 FIDO Alliance의 관련성

FIDO Alliance 는 비밀번호 없는 인증 기술을 탐색하는 조직중 하나이다. OpenID Connect는 이러한 비밀번호 없는 인증 기술을 통합하여 사용자 친화적인 인증 경험을 제공할 수 있는 기반을 마련하고 있다.