[보안] SSO(Single Sign-On) 구현 3 - OIDC(OpenID Connect)

OpenID Connect(이하 OIDC)는 권한 허가 프로토콜인 OAuth 2.0를 이용하여 만들어진 인증 레이어 입니다.

 

OAuth는 위에서 언급했듯이, Authorization을 위한 기술이지 Authentication을 위한 기술은 아닙니다.OAuth에서 발급하는 Access Token은 일시적으로 특정 권한을 허가해준 토큰일 뿐이지 사용자에 대한 정보는 담고 있지 않습니다.
Access Token을 발급하기 위해 사용자 인증을 하긴 하였으나 Access Token이 사용자 인증을 위해 사용되어선 안됩니다.

 

그래서 OIDC에서는 인증을 위해 ID Token이라는 토큰을 추가하였습니다.

 

※ ID Token

Access Token이 Bearer 토큰 형식이었다면,
ID Token은 JWT(JSON Web Token)형식입니다.

 

JWT는 header, payload, signature 3가지 부분이 담겨있는 토큰입니다. ID Token을 얻으면 Client는 payload부분에 인코드 된 사용자 정보를 얻을 수 있습니다.

 

payload에는 claims라는 필드를 포함하게 되는데 기본적인 claims는 다음과 같습니다.

{
  "iss": "https://server.example.com",
  "sub": "24400320",
  "aud": "s6BhdRkqt3",
  "exp": 1311281970,
  "iat": 1311280970
}

• iss(issuer) : 토큰 발행자
• sub(subject) : 토큰의 고유ID
• aud(audience) : 토큰을 요청하는 Client의 ID
• exp(expiration time) : 토큰의 유효시간
• iat(issued at) : 토큰이 발행된 시간

claims 필드는 원한다면 추가로 다른 값들을 추가할 수 있습니다. (ex. eamil, address, id 등)

 

ID Token(JWT)를 통해서 누가 인증을 했는지, 발행자(issuer)가 누구인지 등을 알 수 있습니다.

 

※ 인증 플로우

그럼 OIDC의 인증 플로우에 대해서 살펴보겠습니다.

기본적인 토큰발급과 refresh token으로 토큰을 갱신하는등 일련의 동작들은 OAuth와 동일합니다.
다른 점은 로그인 시, id_token이라는 별도로 발급받게되고 해당 토큰을 통해 유저의 인증을 손쉽게 할 수 있게 됩니다.

• id_token의 audience를 통해 유효한 client로부터 온 토큰인지 검증
• id_token으로부터 user정보를 추출한 뒤, DB와 교차검증

 

※ OAuth2.0 Pseudo Authentication and OPenID

이 포스팅을 만들면서 꽤나 많은 자료들을 읽었는데 이부분이 많이 헷갈려서 정리할 겸 적어둡니다.

 

• 참고 사이트
  • Common pitfalls for authentication using OAuth
  • WIKI:OpenID vs. pseudo-authentication using OAuth

 

먼저 OAuth는 Authorization을 목표로 설계되었으며,
OpenID는 Authentication을 목표로 설계된 툴입니다.

 

하지만 인터넷에 검색해보면 OAuth로 인증을 시도하는 몇가지 사례들을 볼 수 있습니다.(실제로도 OAuth로 인증 프로토콜을 구축하는 것은 가능합니다)
이때 OAuth로 인증하는 것을 Pseudo Authentication이라고 부릅니다.

왜 Pseudo Athentication이라고 할까요?

아래 OAuth로 인증을 시도할 경우의 취약점들을 보면 왜 허위/사칭 인증이라고 적어놨는지 알 수 있습니다.

1. OAuth를 통해 얻는 Access Token은 User인증 후에 발급받게 되기 때문에 인증의 증거로 간주될 수 있으나, 실제로 Access Token에는 User에 대한 정보가 없고 특정 권한에 대한 허가만 존재
2. Access Token을 통해 특정 사용자의 특정 자원에 접근 할 수 있으니 인증의 증거로 생각될 수 있으나, Refresh Token이나 Assertion을 통해 사용자가 인증하지 않아도 Access Token을 발급받을 수 있음
3. 외에도 Access Token의 탈취 가능성, Access Token Injection공격, 다른 Client의 Access Token으로 로그인 위장 공격 등 여러 보안 위협들이 존재

 

OIDC에서는 인증을 위한 id_token 토큰을 따로 두어 위의 위협들을 해소했습니다.

 

따라서 OAuth로 Authentication을 할 수는 있지만 여러 보안위협들이 존재하기 때문에 OIDC나 SAML과 같은 방식을 따르는 것이 안전합니다.

 

※ SSO 개념 보러가기

 

---

 

🎓 Reference

• https://gruuuuu.github.io/security/ssofriends/