1. 서론
소셜 로그인은 다양한 측면에서 장점을 가지고 있어서 많은 사이드 프로젝트, 더 나아가 실무에서도 활용된다. 또 이런 소셜 로그인을 할 때 필수로 따라붙는 OAuth 2.0은 보안성, 편의성, 확장성 등의 장점을 제공하여 많은 애플리케이션에서 선택되고 있다. 이번 Lovebird 프로젝트에서도 로그인 기능으로 많은 리소스를 필요로 하는 자체 로그인이 아닌 소셜 로그인을 활용하기로 했다.
기능 구현 이전에 필자는 Spring Security 스터디를 진행했고, 이번 작업을 통해 OAuth 2.0, OIDC, 더 나아가 JWT에 대해 확실히 이해 해봐야겠다. (이번 포스팅은 OAuth2.0과 OIDC의 비교•분석에 포커스를 두고 있습니다.)
2. OAuth의 등장
OAuth의 탄생에 대해 이해하기 위해서는 Delegated Authorization에 대해 먼저 이해해야 한다. Open API가 대중화 되면서 인증 과정에서 써드파티(Third-Party) 애플리케이션에게 유저의 비밀번호를 노출하지 않고 인증하는 방법에 대해 고민하게 되었고, OpenID가 등장했다. OpenID는 계정 하나로 여러 서비스에 인증하는 개념인데, 또 다른 서비스에 가입해야 한다는 한계점을 가지고 있었다. 이러한 한계점을 보완한 인증 프로세스가 바로 OAuth다.
Delegated Authorization(위임된 권한 부여)은 다른 애플리케이션이 유저 데이터에 액세스 할 수 있도록 허용하는 접근 방식이다. 이 접근 방식은 크게 두 가지 방향성이 있다. 아래를 참고해서 OAuth를 왜 활용해야 하는지 생각해보자.
- i) 제3자 애플리케이션에 계정 비밀번호 제공하여, 제3자가 유저를 대신해 계정에 로그인하고 데이터를 액세스
- ii) 애플리케이션에 비밀번호를 제공하지 않고, OAuth를 사용해 데이터를 액세스
OAuth 2.0에 대한 이론을 자세히 보고 싶다면 해당 링크를 참고해보자.
3. 인증과 인가
OAuth 2.0과 OIDC(OpenID Connect)에 대해 이해하려면 인증(Authentication)과 인가(Authorization)에 대해 먼저 이해해야 한다.
Authentication : the assurance that the communicating entity is the one claimed.
Authorization : the process of verifying whether the communicating entity has access to the resource.
인증은 유저의 신원을 확인하는 작업이고, 인가는 유저에게 특정 리소스나 기능에 액세스할 수 있는 권한을 부여하는 작업이다. 쉽게 말하면, 인증은 유저가 누구인지에 대한 것이고, 인가는 유저가 어떤 권한을 가지고 있는지에 대한 것이다. OAuth 2.0은 인가 프로세스이고, OIDC는 인증 프로세스다.
4. OIDC (OpenID Connect)
이 글을 읽는 사람들은 OIDC가 생소해서 읽었을 것이라 생각이 든다. OIDC(OpenID Connect)는 OAuth2.0 프로토콜을 확장한 인증 방식이다.
OAuth는 사용자 ID를 바로 제공하지 않고 인증을 위한 액세스 토큰을 제공한다. (이 액세스 토큰은 authorization_code라고도 부른다.) OIDC를 사용하면 클라이언트가 인증 서버에서 수행한 인증을 기반으로 사용자를 식별할 수 있다.
또 OIDC는 OAuth 2.0과 다음과 같은 차이점을 가지고 있다.
- 스코프(Scope)
- OAuth 2.0
- 제공자가 원하는 대로 요청 범위를 설정
- 유연한 사용 가능, But 상호 운용이 완벽히는 불가능
- OIDC
- 요청 범위를 openid, 프로필, 이메일, 주소로 표준화
- OAuth 2.0
- 클레임(Claim)
- 요청 범위에 속하는 클레임의 종류 표준화
- sub, email 등
- identity token
- 스코프가 특정한 정보 세트를 요청하는 데 사용 가능
- 써드파티 애플리케이션이 타 어플리케이션에 대해 동일한 인증 정보를 제공받을 수 있음
- 사용자 정보 요청 엔드포인트 통일
- 표준화 된 엔드포인트를 제공
5. 왜 로그인을 하고 다시 인증을 할까?
OAuth고, OIDC고 다 이해가 갔다. 하지만 이해가지 않는 것이 있었다. 이미 구글, 카카오, 애플 등의 Authorization Server에 로그인하면서 인증을 했는데 왜 다시 API Server로 인가 코드(authorization_code)를 보내 인증 관련 처리를 하는 것일까?
이유는 예상 가능하듯이 보안이다. local에서는 상관없지만, 운영 단계에서는 여러 위험에 노출되고, 이 말은 해당 서비스의 클라이언트뿐 아니라 다른 미식별 대상(?)으로부터의 요청을 받을 수도 있다는 것이다. 따라서 API Server에서 따로 인증 프로세스를 거치지 않으면 유저 정보는 모두의 것(?)이 돼버리기 때문에 인가코드를 전달하여 API Server에서 별도의 인증 프로세스를 밟는 것이다.
References
