로그인에 사용하는 OAuth: 과거, 현재 그리고 미래

https://www.youtube.com/watch?v=DQFv0AxTEgM&t=1692s 

 

NHN팀의 회원플랫폼개발팀의 안하운 님의 세션을 듣고 요약하고자 합니다.

 

인증(Authentication)이란?

경찰 : 안녕하세요, 성함이 어떻게 되시나요?

홍길동: 제 이름은 홍길동입니다.

홍길동: 경찰청 직인이 찍힌 운전면허증이 있습니다.

경찰 : 네, 확인하였습니다.

 

인가(Authorization)이란?

대리기사: 대리운전 서비스를 해 드리기 위해 자동차 사용 권한이 필요합니다.

홍길동: 제 자동차 키를 드릴 테니 대리운전해 주세요

 

Oauth란 무엇인가?

가장 많이 사용하는 사례는 소셜 로그인입니다. (네이버, 카카오, 구글, 페이스북, 애플 등등)

OAuth가 발전하고 바뀌게 된 배경과 동기를 알아보고자 합니다.

 

OAuth 1.0

Resource Owner: 회원

OAuth Client: 자원에 접근을 해서 활용하고자 하는 애플리케이션

OAuth Server: Resource Owner의 신분을 

 

흐름

• OAuth Cleint: SNS 사진 에디터 애플리케이션입니다. Resource owner에게 인가를 받고 이 주소로 인가 정보를 보내 주세요
• OAuth Server: 네 알겠습니다. Resource owner를 이 주소로 인증 및 인가를 위해 보내주세요.
• OAuth Client: Resource Owner님 이 주소로 가서 Oauth Server와 인증하세요.
• Resource Owner: 로그인을 수행했고 사진에 접근하는 것을 허용했습니다.
• OAuth Server: 인증/인가가 완료되었습니다. OAuth Client에게 인가 토큰을 발급받을 검증 값을 전달해 주세요
• OAuth Client:  이제 홍길동 씨의 보호된 리소스에 접근하는데 필요한 인가 토큰을 발급해 주세요!
• OAuth Server: 확인되었습니다. 토큰 여기있습니다.
• OAuth Cleint: 홍길동 씨 리소스 접근에 필요한 토큰이 있습니다. 이제 사진을 보내주세요.

 

OAuth 1.0의 문제점

• Scope 개념이 없다
• 토큰 유효기간 문제
• Client 구현 복잡성
• 역할이 확실히 나누어지지 않음
• 제한적인 사용 환경

 

OAuth 1.0에서 엿보는 웹 환경

• 인터넷 초창기에는 간단한 정적리소스를 보았다.

 

OAuth 2.0 인가 프레임워크

• Scope 기능 추가됨
  • Oauth 1.0에는 토큰만 있다면 사용자의 모든 권한이 있었습니다.
  • Oauth 2.0에는 토큰에게 허용된 권한의 접근 범위를 지정합니다.
• Client 복잡성 간소화
  • OAuth 1.0에서는 요청을 위해 암호함적으로 서명을 위해 여러 파라미터를 정렬하고 encode 하는 정확한 분류가 필요했습니다.
  • OAuth 2.0에서는 Bearer Token과 TLS를 통해 해결하였습니다.
• 역할이 확실히 나누어지지 않음
  • Oauth 1.0에서는 Resource Owner 인증, 인가 토큰 발급, 보호된 리소스 발급
  • OAuth 2.0에서는 인증, 인가 토큰 발급은 Authz Sever에서, 보호된 리소스 발급은 Resource Server로 분리하였습니다.
• 토큰 유효기간 문제
  • OAuth 1.0에서는 6개월 1개 월등의 기간이 길었다.
  • OAuth 2.0에서는 refresh token을 활용하여 access token은 유효기간을 짧게 유지하였다.
• 제한적인 사용 환경
  • OAuth 1.0에서는 웹 브라우저 환경에서 동작하기에 최적화되어있었습니다.
  • OAuth 2.0에서는 Grant라는 개념을 통해 여러 환경에서 동작하도록 보장합니다.
    • Authroization Code: 기존과 동일하게 Server to Server 통신
    • Implicit: 간략하게 로그인 인증 후 토큰을 발급받음
    • Resource owner password credentials: 직접적으로 유저의 id와 password를 받아서 통신
    • Client credentials: Resource Owner와 OAuth Client가 동일할 때 직접적으로 API 호출을 통해 토큰을 발급받음

 

OAuth 2.0은 현재 가장 널리 쓰이는 인가 프로토콜과 버전입니다.

 

OAuth 2.0에서 엿보는 웹 환경

• 브라우저, JS, 스마트기기가 등장함

 

OAuth 2.1인가 프레임워크

더 보안적으로 민감한 사용처들의 프로토콜 채택(금융권, 증권, 의료계)

이제 보안이 민감해지게 되고 이를 위한 보완 RFC가 등장하게 됩니다.

안전하게 구현하기 위해 여러 개의 RFC 스펙을 숙지해야 합니다.

https://www.youtube.com/watch?v=DQFv0AxTEgM&t=1692s

OAuth2.0 + 이런 여러 RFC 스펙들을 합친 것이 바로 OAuth2.1입니다.

 

OAuth 2.1의 Grant

• Authroization Code: 기존과 동일하게 Server to Server 통신
• Implicit: 간략하게 로그인 인증 후 토큰을 발급받음
• Resource owner password credentials: 직접적으로 유저의 id와 password를 받아서 통신
• Client credentials: Resource Owner와 OAuth Client가 동일할 때 직접적으로 API 호출을 통해 토큰을 발급받음
• Device Authroization Grant: 스마트기기를 사용할 때 통신하기 편함

Implict 방식과 비밀번호를 받는 방식이 폐지되었습니다.

대신 Device Authorization Grant 방식이 등장하였습니다.

 

OAuth 2.1 PKCE

• 클라이언트가 시작 요청과 Hash 값을 보냅니다.
• 검증값이 보냅니다. (이제 탈취되더라도 괜찮습니다)
• 완료 요청과 동시에 확인값 원문을 보냅니다.

 

OAuth 2.1 Refresh Token

• Refresh Token 또한 1회성이 되어 계속유지되지 않고 변경됩니다.

 

OAuth 2.1에 포함된 그 외 보안사항

• Redirect URL 패턴 매칭 스펙아웃, 정확한 매칭 강제
• URL Query string에서 Bearer token 사용 불가
• mTLS 또는 DPoP 채택
• 그 외 자주 발생하는 버그들에 대한 보완 스펙

OAuth 2.0에서 엿보는 웹 환경

• 스마트 기기가 등장하였다

 

Open ID Connect 인증 계층

홍길동: 안녕하세요 혹시 이 호텔의 직원입니까?

직원: 저는 모든 방을 열 수 있는 마스터키를 보유하고 있습니다.

 

이 사람은 호텔 직원임을 인증했을까요?

 

그렇다고 하기는 조금 어렵습니다.

 

이런 배경으로 Open ID Connect는 OAuth 2.0 기반 인증 계층을 기반으로 인증기능을 추가되었습니다.

추가적으로 ID Token(jwt)를 받습니다.

 

이를 디코드 하면 토큰 발급자, 토큰 사용자, 사용자 식별, 토큰 발급 시간, 토큰 만료 시간등을 알아낼 수 있습니다.

이제 토큰을 가지고 API Call을 하는 대신에 jwt 토큰을 파싱 하여 사용자의 정보를 가져올 수 있습니다.

Open Id Connect에서 엿보는 웹 환경

• 인증서버에 트래픽이 증가하면서 통신의 부하를 줄일 필요가 있다.

 

인증/인가의 미래, GNAP*

하위호환성을 포기하고 현재 진행형으로 Spec을 만들어내고 있습니다.

GNAP은 OAuth2.0을 기반으로 동작하지 않습니다.

하지만 인증/인가의 목적 목표는 동일하고 발전을 하게 됩니다.

 

• Grant -> Interaction으로 변환 (사용자와 어떤 방식으로 상호작용할지 동적으로 결정)
• Scope 접근 범위를 세밀하게 조정가능
• mTLS/DPOP는 구현하기 귀찮은 스펙인데 GNAP에는 JWK, 인증서 기반 Client 보안 내장이 되어있습니다.