[인증] OIDC (OpenID Connect) 에 대하여 Feat. OAuth2

1. OAuth2(open authorization 2.0) 란?
2. OIDC(open id connect) 란?

 

 

OIDC 에 대하여 알아보니 OAuth2 기반으로 작동하는 인증 프로토콜 이다. 

OAuth2 기반으로 작동 한다는게 무엇인지 좀 살펴보니 작동 메커니즘은 OAuth2 와 완전 똑같고 사용자 권한을 바탕으로 특정 데이터에 접근 하지 않고 사용자 인증과 사용자 정보 조회에 관해서만 처리한다.

 

 

그래서 개인적인 생각으론 OAuth2 프로토콜을 사용자 인증 용도로만 사용하는거 같은데

굳이 이걸 또 인증 프로토콜로서 OIDC 라는 명칭을 만들었어야 했을까 라는 의문이 든다.

왜냐하면 처음 OIDC 라는 단어를 들었을때 완전 새로운 프로토콜인거 같은 느낌이 확 들었기 때문이다.

 

 

어쨌든 OIDC 에 대해 알고자 한다면 결국 OAuth2 를 이해해야 한다. 

OAuth2 에 대해 알아보기에 앞서 OAuth2 용어부터 알아보도록 하자.

• Resource Owner : 클라이언트 어플리케이션 사용자
• Client : OAuth2 를 통해 Resource Owner 의 인증 정보를 얻고자 하는 클라이언트 어플리케이션
• Authorization Server : Resource Owner의 신원을 인증해줄 인증 서버
• Resource Server : 인증된 Resource Owner 의 인증 정보를 기반으로 접근 할수있는 데이터 리소스 (API 서버라고 생각하자.)
• Access Token : Resource Server 에 접근하기 위해 필요한 인증 토큰

 

 

1. OAuth2(open authorization 2.0) 란?

써드파티 서비스가 리소스 소유자 (유저) 를 대신하여 리소스 서버(리소스 소유자가 가입한 외부 서비스)에 자원에 대한 접근 권한(crud, only read, etc..)을 흭득하기 위한 프로토콜이다.

 

우선 알게 모르게 우리는 이 OAuth2 프로토콜에 굉장히 익숙할지도 모른다. 왜냐하면 외부 로그인 기능을 제공하는 거의 모든 웹사이트에 이 기술이 적용되어 있기 때문이다.

종종 타 웹사이트에서 회원가입/로그인시 그 사이트에 내 개인정보를 직접 제공하여 회원가입/로그인을 하는게 아니라 네이버, 카카오, 구글, 페이스북 계정을 이용하여 회원가입/로그인을 해본 경험이 있을 것이다.

 

이때 네이버, 카카오, 구글, 페이스북 등과 같이 내 신원을 인증해주는 매체는 Authorization Server 와 Resource Server 가 된다.

 

그리고 OAuth2 를 구현하는덴 몇가지 방법이 있는데 가장 많이 사용되는 2가지 방법에 대해 알아보도록 하겠다.

 

1. Authorization Code Grant (권한 부여 승인 코드 방식)

https://betterprogramming.pub/the-complete-guide-to-oauth-2-0-and-openid-connect-protocols-35ebc1cbc11a

 

 

1.

아래와 같은 버튼을 눌러 외부 계정으로 인증을 시도할수 있다. 그럼 보통 외부 신원 인증 매체가 제공해주는

로그인 페이지로 이동하게 된다.

 

2.

로그인 할 페이지로 이동하면서 Client 식별값 또는 인증 성공 후 리다이렉트 될 URI를 쿼리 파라미터로 같이 넘겨준다.

이미 신원 인증 매체 설정 페이지 ex) 페이스북 개발자 센터 등 에 Client 식별값에 따라 리다이렉트 될 URI 를 지정해 놓았다면 리다이렉트 될 URI는 따로 넘겨주지 않아도 될 것이다.

 

 

3.

로그인 페이지에서 사용자가 아이디와 비밀번호 입력 후 로그인을 시도한다.

회원가입의 경우 Client 가 접근하고자 하는 사용자 정보 scope 에 대한 동의를 구하기도 한다.

 

 

4. 

사용자 인증 성공시 Client 가 미리 지정해둔 URI 로 Authorization Code 와 함께 Client가 지정해둔 URI 로 리다이렉트 시킨다. 

 

 

5.

Authorization Server 로 부터 받은 Authorization Code 를 Client 의 백엔드 서버에 전송한다.

 

 

6, 7.

백엔드 서버에서 이를 다시 Authorization Server 에 전송하여 Access Token 으로 교환 한다. 

 

여기서 Authorization Code 를 바로 사용하지 않고 굳이 백엔드 서버에 전송하여 Acccess Token 으로

교환 하는 이유가 궁금할수도 있다.

 

그 이유는 브라우저의 경우 민감한 값을 저장하기에 적절한 매체는 아니기 때문이다. 왜냐하면 브라우저에 저장되어 있는 값은 항상 탈취 될수도 있다는 것을 알아야하고, 조작에 취약하다. 

그래서 보안상 이유로 Authorization Code 를 굳이 백엔드 서버로 보내 Authroization Server 와 통신하여 Access Token 을 흭득한다.

 

 

8, 9.

Access Token 을 이용해 인가된 접근으로서, Resource Server 와 통신한다. 

좀더 강화된 보안을 위해 PKCE(Proof Key for Code Exchange) 를 추가하여 인증 하기도한다.
- https://oauth.net/2/pkce/

 

 

2. Implicit Grant (암묵적 승인 방식)

https://betterprogramming.pub/the-complete-guide-to-oauth-2-0-and-openid-connect-protocols-35ebc1cbc11a

Implicit Grant (암묵적 승인 방식) 의 경우 보통 Client 단 백엔드 서버가 따로 없는 어플리케이션에서 쓰이기도 한다.

전체적인 흐름은 Authorization Code Grant (권한 부여 승인 코드 방식) 똑같지만 큰 차이점이 하나 있다.

 

Authorization Code Grant (권한 부여 승인 코드 방식) 의 경우 보안을 위해 백엔드 서버를 거쳐서  Access Token 을 발급 받아 보안을 향상 시키고 브라우저에는 민감한 값을 저장하지 않는다. 

 

하지만 Implicit Grant (암묵적 승인 방식) 은 이 Access Token 값을 브라우저에 저장하여 Resource Server 와 통신하기 때문에 보안에 취약하다.

 

보안 문제 때문에 Implicit Grant (암묵적 승인 방식) 은 deprecated 되었고, 사용하지 말자.

 

 

2. OIDC(open id connect) 란?

위에서 봤듯이 OAuth2 프로토콜을 통해 사용자 인증후, 특정 리소스에 대한 사용자 권한을 흭득하여 외부 서비스의 사용자 정보를 활용 할수 있다.

 

그리고 이를 활용하여 Authorization Server 를 통해 사용자 인증을 받고 Authorization Server 를 통해 사용자 정보만을 얻고자 한게 OIDC 이다.

https://betterprogramming.pub/the-complete-guide-to-oauth-2-0-and-openid-connect-protocols-35ebc1cbc11a

결국 메커니즘은 Authorization Server 에서 받은 Authorization Code 를

다시 Authorization Server 와 통신하여 사용자 정보 토큰 (JWT)과 교환하여 사용자 정보를 알수 있게 된다.

 

 

참고자료

https://betterprogramming.pub/the-complete-guide-to-oauth-2-0-and-openid-connect-protocols-35ebc1cbc11a

https://blog.naver.com/mds_datasecurity/222182943542