OAuth 인증의 이해 3 - OIDC

지우긴요. 많이 배웠습니다. 이 토픽이 시작되고 저도 이해해보려 노력하는 과정에서 알아낸걸 공유합니다.

일단 OAuth 와 OIDC 프로토콜은 그 상위개념인 IDP (아이덴티티 프로바이더) 프로토콜이고,

인가만 있는 OAuth 프로토콜을 확장해서 인증+인가를 구현하는게 OIDC 프로토콜이라는 군요. OAuth 도 인증이 있지만 간소화된 절차고요.

OAuth 는 API 인가에,
OIDC 는 SSO에
적합하게 나누어져 있군요. 저는 SSO를 위해 OAuth를 파고 있던거였군요 ㅎ

이 IDP 프로토콜이 복잡하게된 가장 핵심적인 것은 ‘서로다른’ 도메인(도메인+포트넘버) 혹은 서비스, 클라이언트 상황에서 유저 비밀정보(계정정보나 토큰)를 노출하지 않기 위함이라고 파악했습니다.

SSO는 A사이트 회원이 B서비스를 A계정으로 이용하려 할 때 B에 A계정 정보를 넣지 않고도 B서비스에 로그인해서 사용할 수 있게하는게 목적인데요.

같은 서비스회사의 여러 클라이언트/웹앱을 이용하는데도 마찬가지로 클라이언트에 계정정보를 남기지않고 중앙관리 할 수 있기도 하고요.

그런데 서로다른 도메인이기 때문에 브라우저 CORS 보안정책과 맞물려 비밀정보(ID토큰, 리소스액세스토큰)을 노출하지 않고 공유할 방법이 저러한 프로토콜이란 것이네요.

그래서 보안관점에서 교환 가능한 수단과 데이터가

  • 클라이언트 간 통신과 (브라우저 리다이렉트시 쿼리스트링, 노출해도 큰문제없는 매우짧은 만료시간의 난수 key등)
  • 서버 간 통신에서 (api, ID 토큰, 액세스토큰등 )
    달라지는 것이고요.

저는 외부 SSO 뿐만아니라 최근 같은 도메인의 다른 MS 앱간에 로그인 공유를 구현하려고 했는데 이로써 같은서버(도메인)내 앱에선 채택할 이유가없는 프로토콜인걸 알게 되었습니다.

같은 도메인에서는 민감한 토큰을 authorization 헤더, 쿠키나 세션, 서버간통신으로 바로 교환 가능하니까요.

혹시 틀린 내용이 있다면 바로잡아주시면 감사하겠습니다. 이제 코딩해야 해서요 ㅎㅎ

2개의 좋아요

맞습니다. OAuth 와 OIDC의 핵심 키워드는 Third Party 입니다.
내부 시스템 끼리에서는 사용할 이유가 없죠.

1개의 좋아요