소셜 로그인을 구현해 봤거나, 공부했다면 접했을 단어들이다.
이 두 가지 방식의 흐름을 정리해 보고자 한다.

OAuth2.0?

인증을 위한 개방형 표준 프로토콜로 Third-Party 프로그램에게 리소스 소유자를 대신하여 리소스 서버에서 제공하는 자원에 대한 접근 권한을 위임하는 방식이다.

Delegated Authorization(위임된 권한을 부여한다)

다른 애플리케이션이 사용자 데이터에 접근할 수 있도록 허용하는 방식이다.
어쨌든, Third-Party 프로그램에 사용자의 정보를 노출하는 방식이기 때문에, 이에 대해서 계정과 비밀번호를 제공할 것인지, 혹은 비밀번호를 제공하지 않고 접근할 것인지에 고민하며 나온 방식들이 OpenId, OAuth 라고 한다.

인증과 인가의 차이

이 두 가지 개념이 많이 혼동되기도 하고, 본 글의 목적에 닿아있기에, 먼저 설명해 보자면

인증(Authentication)

• 사용자의 신원을 확인하는 작업
• 사용자가 누구인가?

인가(Authorization)

• 사용자에게 특정 리소스나 기능에 접근할 수 있는 권한을 부여하는 작업
• 사용자가 어떤 권한을 갖고 있는가?

이 두가지 개념의 차이가 OAuth2.0 REST API 방식과 OIDC 방식의 차이를 가르는 것이다.

OIDC(OpenID Connect)

OpenID는 사용자 인증을 목적으로 하는 개방형 표준 및 분산 인증 프로토콜이다.

• OIDC는 OAuth 2.0을 확장하여 사용자 인증 정보를 id_token(JWT)으로 제공하며, 통신 횟수를 줄여 효율적인 인증 과정을 가능하게 한다.
• OAuth 2.0의 스코프를 활용해 추가적인 사용자 정보를 id_token에 포함시킬 수 있어, 사용자 신원 정보를 더욱 풍부하게 제공할 수 있다.

주목하고 싶은 것은 OAuth2.0의 확장 이라는 것이다.

id_token이 핵심적인 역할을 한다. OAuth2.0 REST API 방식을 구현해 봤다면, access_token 이라는 것을 확인해 본 적이 있을 것이다.
이 토큰은 해석하려 해도, 사용자 정보를 담고 있지 않아 활용할 수 없었지만 Id_token은 사용자의 정보를 담고 있어 해석이 가능하고 이를 활용할 수 있다.

마무리

어쨌든 두 가지 방식 모두 사용자의 편의를 위한 방식이고, 이를 활용하고 API 서버에서 2차적으로 인증(JWT와 같은) 방식을 구현하며 보안적인 수준을 높일 수 있는 방법이다.

어떤 방식을 선택하느냐는 다양한 상황을 고려해야겠지만 약간의 구현 방식의 차이가 있다면

• OAuth2.0: 백엔드에서 인가 서버에 요청 후 권한을 받고 이후 클라이언트와 인증할 2차 인증 과정을 거침
• OIDC: 클라이언트에서 id_token 발급 받은 후 백엔드와 통신, 이후 백엔드에서 클라이언트와 인증할 2차 인증 과정을 거침

필자가 구현한 방식이니 정답도 아니고, OIDC의 모든 과정을 백엔드에서 당연히 진행할 수 있는 것으로 알고있다.

아무튼. 소셜 로그인은 요즘 대부분의 서비스에서 제공하는 만큼 개발자로서 조금은 알고 써보자는 마음으로 글을 써본다.