[Back-end] OpenID

Geun·2022년 4월 6일
Backend
0

Back-end

목록 보기
47/74
post-custom-banner

최근에는 복잡한 절차없이 간단한 신상확인 만으로도 인터넷 서비스에 가입하는 일이 많다.
이것은 IDP(IDentity Provider)라고 불리는 신원확인 서비스가 제공해준다.
IDP는 SAML(Security Assertion Markup Language), OAuth 2.0, OIDC(OpenID Connect)같은 표준을 기반으로 사용자를 인증하거나 특정 리소스를 이용하도록 허가 또는 관리한다.

위에 언급한 IDP 표준들을 간단히 정리하면 다음과 같다.

  • SAML 2.0 : 2001년 OASIS에서 정의한 개방형 Authentication(인증) 및 Authorization(인가) 표준이며, 엔터프라이즈 애플리케이션의 SSO(Single Sign On)를 목적으로 XML(Extensible Markup Language) 형식으로 개발되었다.
  • OAuth 2.0 : 2006년 Twitter와 Google이 정의한 개방형 Authorization 표준이며, API 허가를 목적으로 JSON(Javascript Object Notation) 형식으로 개발되었다.
  • OIDC 2.0 : 2014년 OpenID Foundation에서 정의한 개방형 Authentication 표준이며, 컨슈머 어플리케이션의 SSO를 목적으로 JSON 형식으로 개발되었다.

OpenID

OpenID는 오픈된 Identity를 의미한다.
서로 연계된 서비스간에 사용자의 인증을 오픈해주는 기술이다.
OpenID 기술을 정확하게 표현하면 OIDC, OpenID Connect이다.

OpenID Connect

OAuth 2.0은 권한관리를 위해 사용된다.
OpenID Connect는 인증을 위해 사용된다.
OpenID Connect는 OAuth 2.0 기능을 확장한다.
OpenID Connect는 권한부여 서버에 의해 작동하는 인증시스템을 기반으로 클라이언트가 사용자를 판단할 수 있게 해준다.
권한부여 서버에 유저 로그인과 동의를 요청할 때 openid라는 스코프를 정의하면
OpenID Connect 사용이 가능해진다.
openid는 OpenID가 필요한 권한부여 서버에서 필수적인 스코프이다.

OpenID Connect 인증을 위한 URI 요청은 다음과 같다.

https://accounts.google.com/o/oauth2/v2/auth?
response_type=code&
client_id=your_client_id&
scope=openid%20contacts&
redirect_uri=https%3A//oauth2.example.com/code

이 결과는 액세스 토큰과 ID 토큰으로 바꿀 수 있는 애플리케이션 코드이다.
OAuth 플로우가 암묵적 플로우라면 서버는 액세스 토큰과 ID 토큰을 바로 줄 것이다.

ID토큰은 JWT 또는 JSON 웹 토큰이다.
JWT는 Header, Payload, Signature의 세가지 부분이 담겨있는 인코드된 토큰이다.
ID 토큰을 얻은 후에 클라이언트는 payload 부분에 인코드된 사용자 정보를 얻을지 결정할 수 있다.

{
  "iss": "https://accounts.google.com",
  "sub": "10965150351106250715113082368",
  "email": "seedfake@example.com",
  "iat": 1516239022,
  "exp": 1516242922
}

Claims

ID 토큰이 갖고 있는 payload는 claims라고 알려진 어떤 필드들을 포함한다.
기본적인 claims는 아래와 같다.

  • iss: 토큰 발행자
  • sub: 사용자를 구분하기 위한 유니크한 구분자
  • email: 사용자의 이메일
  • iat: 토큰이 발행되는 시간을 Unix time으로 표기한 것
  • exp: 토큰이 만료되는 시간을 Unix time으로 표기한 것

claims는 이런 영역에 제한되지 않는다.
권한부여 서버에서 어떻게 claims를 인코드할 것인지에 달려있다. 클라이언트는 이런 정보를 이용해 사용자를 인증할 수 있다.

클라이언트가 더 많은 사용자 정보를 원한다면, 클라이언트는 표준 OpenID Connect 스코프에 더 많은 것을 기재해서 권한부여 서버에게 ID Token의 payload에 필요한 것을 더 추가하라고 할 수있다.
이런 스코프는 email, address, phone, profile등이 있다.


OpenID Connect 작동원리

전자상거래 서비스 eBay를 예로.
서비스를 이용하기 위해 회원가입을 하는 경우 eBay 웹사이트에 직접 개인정보를 입력하는 절차를 거칠 수도 있지만 이미 보유한 Google 계정을 이용하면 OpenID Connect 프로토콜을 통하여 간단하게 서비스에 가입할 수 있다.

OpenID Connect는 OAuth 2.0 프로토콜을 기반으로 상위계층에서 간편하게 인증을 처리한다. 신원확인 서비스(IDP)를 통해 보다 안전한 방식으로 사용자 정보를 제공할 수 있다.
위의 그림에서는 OP(OpenID Provider) 역할을 하는 Facebook, Google이 IDP이다.

다음은 OpenID Connect의 작동방식이다.

  1. eBay 서비스를 이용하기 위해 Sign in with Google 버튼을 클릭하면 OP(Google)는 eBay 사용 시 필요한 인증화면(예: 로그인, 인증 번호 입력 등)을 내려 주게 된다. 참고로 eBay는 사전에 해당 OP를 사용하기 위해 인증이 가능하도록 등록을 마쳤으며, 필요한 client id, client secret 같은 정보들을 OP로부터 제공받은 상태이다.
  2. 인증레벨에 따라 다양한 인증방법을 요구할 수 있다. eBay는 OP로부터 발급받은 client id를 비롯해 redirect uri, scope 등의 정보로 OP에 Authorization Code(허가 코드)를 요청한다.
  3. OP는 인증 및 인가 여부를 판단하여, 1회용 Authorization Code를 eBay에 발급한다.
  4. eBay는 전달받은 코드 및 client id, client secret 등의 정보로 OP에 Access 토큰과 ID 토큰을 요청하게 된다.
  5. OP는 Access 토큰 및 ID 토큰을 eBay로 전달한다.
  6. eBay는 Access 토큰을 이용하여 다른 RS(Resource Server) 자원들을 요청할 수 있게 된다.

OpenID Connect가 OAuth 2.0을 기반으로 상위계층에서 간편하게 인증을 처리하게끔 만들어졌기 때문에 OAuth 2.0의 흐름과 크게 다르지 않다.

OpenID Connect는 Access 토큰과 ID 토큰을 전달한다.
이 JWT(JSON Web Tokens)를 통해 암호화된 토큰 안에 사용자 정보를 비롯한 다양한 정보를 HTTP 헤더의 최대 사이즈인 4KB 이내로 저장할 수 있다.
이로 인해 eBay는 Access 토큰을 사용해 OAuth 2.0 API를 호출할 필요없이 사용자 정보가 담긴 ID 토큰을 복호화하여 바로 사용할 수 있게 된다.

예를 들어, 5천만명의 사용자들이 eBay를 이용할 경우 사용자 정보를 가져오기 위해 최소 1억번의 API호출이 필요하다.
이때 ID 토큰을 이용하면 그 절반인 5천만번 정도만 호출하면 된다.

JWT 표준을 이용해 만들어진 ID 토큰은 위 그림과 같다.
해당 토큰은 Header.Payload.Signature로 .을 구분자로 하여 구성된다.

Header에서는 singing 알고리즘 종류를 선택할 수 있고, 지원하는 라이브러리에 따라 HS264, HS384, HS512
RSA264, RSA384, RSA512 등을 지정해 사용할 수 있다.


특징

  • 상호운용성
    인증 서비스는 기본적으로 다양한 컨슈머 서비스들이 사용할 수 있도록 상호운용성을 반드시 충족해야 한다. OIDC 또한 표준영역(openid, profile, email, address, phone)에 대해 요청 시 필요한 사용자 정보들을 ID 토큰을 통해 제공할 수 있다.

  • 단순성, 모바일 지향 형식
    JSON(Javascript Object Notation) 기반의 REST 친화적인 구조를 채택하여 손쉽게 사용할 수 있다.

  • 보안
    ISO/IEC 29115 Entity Authentication Assurance 프레임워크의 레벨 1~4를 선택할 수 있다. 레벨이 높을수록 인증 시 PIN과 같은 추가적인 정보를 요구할 수 있다. eBay 회원가입 창에서 'Sign in with Google'을 통해 인증할 경우 추가적으로 인증번호를 물어오는데 이는 레벨 2를 지정하여 사용하는 것으로 유추된다.

  • 유연성
    OP에 직접 요청을 할 수 있는 Normal 타입, JWT를 이용하여 서명된 데이터 소스를 모두 OP를 통해 전달하는 Aggregated 타입, 데이터 소스를 RP(Relying Party)에서 직접 Access 토큰을 사용하여 전달받는 Distributed 타입이 있으며, 이 중 하나가 아닌 여러 타입을 결합한 하이브리드 형태로도 사용할 수 있다.


참고자료

https://info.orcid.org/ko/faq/what-is-openid/
https://www.samsungsds.com/kr/insights/oidc.html
https://www.ibm.com/docs/ko/sva/9.0.7?topic=concepts-openid-connect
https://velog.io/@jakeseo_me/Oauth-2.0%EA%B3%BC-OpenID-Connect-%ED%94%84%EB%A1%9C%ED%86%A0%EC%BD%9C-%EC%A0%95%EB%A6%AC
https://medium.com/@saltmine_olive/openid%EB%9E%80-%EB%AC%B4%EC%97%87%EC%9D%BC%EA%B9%8C%EC%9A%94-e4565502ef92

profile
Geun
이전 포스트

[Back-end] Cookie 기반의 사용자 인증

다음 포스트

[Back-end] SAML

post-custom-banner

0개의 댓글