OAuth 2.0

OAuth 2.0

• 인가 프레임 워크

Authorization(인가)

인증을 받은 사용자가 이후 인증이 필요한 서비스를 이용할 때 서버에서 로그인(인증된 사용자)인지 확인 후 허가를 해주는 것

동작 방식

전체적인 Flow

• 서버에서 사용자의 서비스 권한을 확인

• 권한이 없으면, 인가가 필요하다는 알림을 사용자에게 노티

• 사용자는 서비스에 인가 요청

• 서비스는 인가가 완료되었다는 임시 코드를 발급

• 사용자는 받은 임시 코드를 서버에 전달

• 서버는 이 코드를 이용해 서비스 접근 권한을 갖는 토큰을 생성하고 저장

• 사용자는 해당 토큰을 통해 서비스를 이용

• ID와 PW는 발급받은 후 변경하지 않는 한 무기한 사용할 수 있는 반면, 토큰은 발급 시점 이후 제한된 시간 동안만 유효하여 특정 권한을 무기한 허용하지 않습니다.

• 토큰을 안전하게 보관하는 것도 중요하지만, 만약 잃어버렸을 때 피해가 적도록 해야 합니다.

세부적인 Flow

• 인증 토큰을 얻기 위해서 클라이언트(서버)에게 요청

  • 클라이언트가 앱이나 브라우저를 많이 가리켜서 헷갈릴 수 있음. OAuth 2.0 인가 과정에서 주체가 되는 것을 가리키는 말

• 인가를 시작하면 서버는 인증을 해야할 위치로 리다이렉트 응답을 보냄

  • 위치에는 인가에 필요한 파라미터들을 추가

  • client_id: 클라이언트의 식별자

  • response_type: 어떤 인가 방법으로 보낼지 명시.

    • code는 OAuth 2.0의 가장

      기본적인 방법인 인가 코드 플로우를 뜻함.

  • scope: 인가할 접근 권한

  • redirect_uri: 인가를 마친 후 다시 돌아올 URL

• 리다이렉트 응답은 받은 브라우저는 해당 Location으로 리다이렉트.

  • 인가 서버는 사용자가 인증할 수 있는 페이지를 보여줍니다.

• 인증이 완료되었다면 브라우저에서 접근 권한을 확인하고 사용자가 승인

• 인가 서버에서 승인이 완료되면 인가 코드를 발급하여 처음 요청할 때 전송했던 redirect_uri뒤에 추가적인 쿼리 파라미터를 추가해서 브라우저에게 리다이렉트 응답을 보냄

• 리다이렉트 응답을 받은 브라우저는 Location으로 그대로 리다이렉트

  • 요청을 받은 클라이언트 서버는 전달받은 code와 client_id그리고 client_secret을 같이 인가 서버에 전송하여 토큰을 발급

• 인가 서버는 이를 검증하고 문제가 없다면 접근 권한 토큰을 응답

OAuth 2.0 보안 취약점

CSRF 공격

사용자가 의도하지 않은 행동을 하도록 하여 세션을 탈취하거나 공격자의 세션을 집어 넣는 공격

• OAuth는 두 가지의 채널을 사용

Front Chanel: 브라우저를 통해서 데이터를 전달

• 리다렉트를 통해서 인가 서버로 필요한 데이터를 전송하고, 인가 코드도 리다렉트를 통해서 전달

• 프론트 채널을 이용하는 이유는 사용자가 제 3자 서비스(인가 서버)에 직접 인증을 해야 하기 때문

• 프론트 채널을 통해 전송되는 모든 정보는 공개되고 유출될 수 있기에 적절히 보호하지 않는다면 사용자의 정보가 위험에 노출된다.

• client_id, scope(접근 권한), redirect_uri, code(인가 코드) 모두가 공개되기 때문에 각각을 적절하게 보호해야 한다.

  • 브라우저 히스토리, 와이어 샤크 패킷 분석기 등

  • URL은 암호화가 안되기 때문

• scope: 권한을 나타냄

  • Github OAuth의 경우 처음 등록할 때의 권한과 다르면 거절하는 등으로 처리

• client_id 식별자

  • 가짜 사이트를 만들어 허용된 client_id를 가져와 인증하도록 하면 마치 내거인거마냐 아이디를 흉내낼 수 있음

  • client_secret은 backend chanel로만 전송되고 미리 등록하기 때문에 토큰을 교환하는 과정에서 해당 데이터를 가지고 client_id 주인 식별가능

  • redirect_uri: code를 얻고나서 어디로 돌아올지에 대한 데이터

    • 악의적으로 경로를 바꾼 요청을 보내서 인가 코드를 탈취

    • redirect_mismatch -> 처음 등록된것과 다르면 거절

      • 완전 일치 검사, 하위 URL 허용, 도메인 검사 등 유연하게 처리하게 설정할 수 있지만 보안적으로는 취약해짐

  • code: 토큰을 교환하기 위한 코드

    • 인가 코드는 제일 중요한 정보로 탈취되어서는 안된다.

    • 그래서 인가 서버는 한 번 사용한 코드는 두 번 다시 사용할 수 없도록 폐기해야 한다

    • state파라미터를 추가하여 CSRF 공격을 방지

    • state: 알기 어려운 문자열, 요청한사람과 인가한사람이 같은지 판별 (CSRF 방지하기 위함)

      • 클라이언트(서버)가 인가 서버로 리다이렉트 하기 전에 사용자의 세션에 state라는 임의의 변수를 하나 생성해서 같이 전달

      • 인가 서버는 인가 코드와 함께 state를 받은 그대로 돌려줘서 처음에 세션에 등록했던 state와 비교

      • 만약 이 state가 없거나 다르다면 요청을 거부

      • state를 변경해서 공격하더라도 서버의 세션은 외부에서 접근할 수 없기 때문에 공격을 방지할 수 있다.

Backend Chanel: 서버와 서버간 통신하는 채널

• 사용자와는 상관없이 시스템을 통해서 데이터를 전달

• 프론트 채널을 통해 받은 인가 코드를 이용해서 접근 권한 토큰을 요청

• HTTPS를 통해 암호화를 이용해 데이터를 주고받기 때문에 데이터가 유출될 가능성이 적음

OAuth 인증

OAuth 2.0이 주로 간편 로그인을 구현하기 위해 사용되다 보니, 사람들은 OAuth 2.0을 인증 프르토콜이라고 생각합니다. 하지만 OAuth 2.0은 인증 프로토콜이 아닙니다.

OAuth 2.0에서 토큰은 불투명합니다. 리소스에 접근할 수 있는 토큰은 인가 서버에서 받은 그대로 저장하고 그대로 전달하여 리소스를 얻는 데 쓰입니다. 이 토큰이 어떤 형식인지는 OAuth 2.0 자체에서 정의되어 있지도 않습니다. 그러다 보니 이 토큰을 불투명하게 관리됩니다.

이 토큰을 가지고 무언가를 할 수 있다고 해서 그 사람이 확인되는 것은 아닙니다. 예를 들어서 아파트 현관 문을 택배기사님들이 열 수 있다고 해서 택배기사님이 우리 아파트 주민이 되는 것은 아니죠. 우리는 단순히 택배를 받기 위해서 문을 열 수 있는 권한을 인가한 것 뿐입니다.

• OAuth는 인가를 위한 프레임워크, 인증을 대신해주기 위해 쓰는것은 아님

  • 인증과 인가는 다르다.

• 사용자 정보를 얻을 수 있도록 인가는 했지만 인증은 서버에서 처리해야함

• 즉, OAuth는 인증을 위한것이 아닌 인가를 함으로써 "이걸 할 수 있으니까 이 사람이 맞겠지" 정도로 타협하는것

• 사용자를 얻는것 까지만 OAuth 서비스를 이용하고 그걸 가져와서 우리 데이터에 사용자가 저장이되면 이후부터 해당 데이터로 주고받아 인증처리를 함

OpenID Connect Protocol

이러한 문제를 해결하기 위해 나온 인증 프로토콜

• OpenID Connect는 OAuth 2.0 인가 프레임워크를 확장

• 다른 서비스가 인증을 대신 수행하도록 하는 프로토콜

• OAuth를 확장한것이라 토큰을 얻는 과정은 완전히 동일함

• 토큰을 받을 떄 인가와 관련된 토큰 뿐만 아니라 id_token이라고 해서 인증받은 토큰을 추가로 받는다.

• 해당 토큰에는 누가 발행했고 언제 만료되는지, 누구인지에 대한 데이터가 JWT 형식으로 저장되어있음

• 해당 토큰을 서버나 사용자가 관리하면 됨

  • JWT 형식이라 아무나 만들 수 없지만 누구나 검증이 가능하기 때문