OAuth 2.0 Security Considerations

1. Client 인증

• Authorization Server는 클라이언트 인증을 위한 자격증명(client_id, client_secret)을 설정

• Authorization Server는 Client pw보다 강력한 인증수단 사용 권장 (mTLS, JWT)

• 발급받은 client_secret은 기밀성을 반드시 보장해야 함

• Authorization Server는 Native Application(.apk, .ipa 등)와 같이 사용자가 직접 실행하는 Application에 기밀성이 요구되는 정보를 발급하지 않아야 함 (리버스 엔지니어링을 통해 유출 가능)

• 특정 장치에만 바인딩되는 동적 기밀정보는 특정 상황에 한해 발급 가능하나, 권장하지 않음

• Client 인증이 불가능한 경우(안전한 기밀정보의 보관이 불가능한 Client) 대체 수단을 사용해야 함

• 대체 수단으론 redirect_uri, Resource Owner의 확인 등이 존재

• redirect_uri 만으론 신원 확인을 보장해선 안됨 (피싱 앱 등의 우려로 인해)

• Authorization Server는 인증되지 않은 Client와 상호작용할 때 발생가능한 모든 보안영향을 고려하고, 해당 클라이언트에 발급된 다른 자격증명 노출 위험을 최소화 해야함

---

2. Client 사칭

• Client의 자격증명이 유출될 경우 사칭 위험이 큼

• Authorization Server는 가능한 모든 상황에서 Client를 인증해야 함

• Client 인증이 불가한 경우 Redirect URI를 사전에 등록하도록 요구해야 하며, 추가적인 방어 수단을 활용해야 함

• Authorization Server는 명시적인 Resource Owner 인증 절차를 적용하고, Resource Owner에게 scope와 lifetime에 대한 세부 정보를 제공해야 함

• Resource Owner는 상기한 정보를 검토 후, 승인 혹은 거부할 책임이 존재

• Authorization Server는 Client를 인증하지 않거나 타 방어 수단을 통해 요청을 검증하지 않는 한 Resource Owner의 적극적인 상호작용 없이 반복된 인가 요청을 자동으로 처리해선 안됨

---

3. Access Token

• Access Token Credentials은 전송 및 저장 시 기밀로 유지되어야 하며 Authorization Server, Access Token이 유효한 Resource Server, Access Token이 발급된 Client Server 간에만 공유되어야 함

• Access Token Credentials은 [RFC 2818]에 정의된 서버 인증을 사용한 TLS를 통해야만 함

• Implicit Grant 유형을 사용할 때 Access Token이 URI fragment에 전송되어 노출 우려 존재

• Authorization Server는 무단 제3자가 유효한 Access Token을 생성, 변경, 추측하여 획득하지 못하도록 보장해야 함

• Client는 최소한의 scope만 요청해야 함

• 서버는 Client의 정체를 고려해야 하며, 요청된 권한보다 적은 권한을 발급 가능

RFC 2818 : TLS 핸드셰이크 중 제시되는 서버 인증서 검증 절차

---

4. Refresh Token

• Authorization Server는 Web Application Client & Native Application Client에게 Refresh Token 발급 가능

• Refresh Token은 전송 및 저장 시 기밀을 유지해야 하며 Authorization Server와 Refresh Token이 발급된 Client 간에만 공유되어야 함

• Refresh Token은 Client에 바인딩 되어 특정 Client에만 유효하도록 설계되어야 함

• Resource Owner, 타 Client에 노출되어선 안되기에 [RFC2818] 섹션 1.6에 설명된 TLS 등의 전송 보안이 필요

• Client 인증 불가 시, Authorization Server는 Refresh Token 남용을 탐지하기 위한 수단 배포 필요. Refresh Token Rotation, 일회용 토큰 등

Refresh Token Rotation: Refresh Token을 사용한 즉시 Access Token 발급과 함께 기존 토큰 파기

---

5. Authorization Code

• Client와 Authorization Server간 교환되어 Access Token을 얻는데에 사용

• Authorization Code의 전송은 보안 채널을 통해 이루어져야 함

• Client가 네트워크 리소스를 식별하는 경우 Redirect URI에 TLS 사용을 요구해야 함

• Authorization Code는 User-Agent Redirection을 통해 전송되므로 잠재적인 노출 가능성 존재

• Authorization Code는 plaintext bearer credentials로 작동하며 Authorization Server에서 권한을 부여한 Resource Owner가 프로세스를 완료하기 위해 Client로 돌아오는 동일한 Resource Owner인지 확인 함

• Client가 자체 Resource Owner 인증을 위해 Authorization Code에 의존하는 경우 Client Redirection EndPoint는 TLS 사용을 요구해야 함

• Authorization Code는 짧은 수명, 단일 사용 조건을 만족해야함

• Authorization Server가 Access Token 교환을 위해 Authorization Code에 대한 여러 시도를 관찰 시 해당 코드 기반으로 부여된 모든 Access Token을 파기해야 함

• Client를 인증 가능한 경우 Authorization Server는 Client를 인증하고 Authorization Code가 동일한 Client에 발급되었는지 확인해야 함

User-Agent Redirection: OAuth 2.0 흐름에서 인가 서버가 권한 부여 코드나 액세스 토큰을 클라이언트 애플리케이션에 전달하기 위해 사용자의 브라우저(=User Agent)를 특정 URL로 이동시키는 과정

---

6. Authorization Code Redirection URl 변조 방지

• Authorization Code로 권한 부여를 요청할 때 Client는 redirect_uri 파라미터를 통해 Redirection URI 지정 가능
• 공격자가 redirect_uri 파라미터 조작 가능하다면 인증 서버를 공격자 서버로 유도 가능
• Authorization Server는 권한 부여 코드를 얻는데 사용된 Redirection URI가 Access Token 교환시 제공된 Redirection URI와 동일한지 반드시 확인해야 함

---

7. Resource Owner PW Credentials(ROPC)

• Client Application에서 Resource Owner가 직접 계정정보를 넘겨 처리하는 것
• Client가 Resource Owner에게 극도로 신뢰받는 경우에만 사용 가능
• Authorization Server는 scope와 수명을 제한하고, 보안을 강화해야 함
• 해당 유형을 가능한 한 최소화하고 다른 유형을 활용해야 함

---

8. Request 기밀성

• Access Token, Refresh Token, Client Credentials등 기밀정보가 포함된 모든 Request는 TLS를 사용하여 전송해야 함

• Authorization Code는 가급적 평문 전송을 피하는걸 권장

• Client와 Server는 모든 기밀정보에 대한 기밀성과 무결성을 보장해야 함

• Client와 Server는 보안이 보장되지 않는 채널의 요청을 거부해야 함

• state와 scope 파라미터엔 기밀정보나 Resource Owner 정보를 평문으로 담아선 안됨

• 상기한 파라미터는 취약한 채널로 전송되거나 안전하지 않게 저장될 수 있음

---

9. EndPoint 진위 확인

• MITM 공격을 방지하기 위해, Authorization Server는 권한 부여 및 토큰 EndPoint로 전송되는 모든 요청에 대해 [RFC2818]에 정의된 서버 인증과 함께 TLS 사용 요구

• Client는 [RFC6125]에 정의된 대로, Server의 ID 인증 요구 사항에 따라 Authorization Server의 TLS 인증서를 검증해야 함

---

10. Credentials-Guessing Attacks

• Authorization Server는 공격자가 Access Token, Refresh Token, Authorization Code, Resource Owner Password, Client Credentials를 추측하는 것을 방지해야 함

• 생성된 토큰을 공격자가 추측할 확률은 2^(-128)보다 작아야 함

• 생성된 토큰을 공격자가 추측할 확률은 2^(-160)보다 작기를 권고됨

• Authorization Server는 최종 사용자의 사용을 위한 Credentials을 보호하기 위해 추가적인 보안조치가 필요함

---

11. Phishing Attacks

• OAuth와 같은 인증 프로토콜이 늘어남에 따라 사용자는 Redirection과 PW를 입력하는 경험에 익숙해짐

• 매 리다이렉트 순간마다 사용자가 검증하지 않으면 피싱 가능

• 서비스 제공자는 최종 사용자를 교육하고, 사용자가 사이트를 쉽게 확인 가능한 메커니즘을 제공해야 함

• 피싱 공격의 위험을 줄이기 위해, Authorization Server는 최종 사용자와의 상호작용에 사용되는 모든 EndPoint에서 TLS 사용이 요구됨

---

12. CSRF

• CSRF 공격이 Client의 Redirection URI에 대해 이루어지면, 공격자의 Authorization Code, Access Token을 주입 가능.

• 상기한 공격의 결과로 공격자가 제어하는 자원에 피해 사용자 정보를 저장하거나 악의적인 동작 수행 가능

• 따라서 Client는 Redirection URI에 대한 CSRF 방어를 구현해야 함

• Redirection URI로 들어오는 모든 요청에 User-Agent 인증상태와 결합된 값을 포함하도록 요구

  • Client의 권한 요청 시 state 파라미터 사용. 콜백 요청 받을 시 state 값을 비교 확인

State 파라미터 전달 예시

https://auth.example.com/authorize?
  response_type=code&
  client_id=abc123&
  redirect_uri=https%3A%2F%2Fclient.example.com%2Fcallback&
  state=m5K8zQ1rYn

• Authorization Server가 자체 인증 EndPoint에 대한 CSRF 방어를 구현하고, Resource Owner의 인지 및 명시적 동의 없이 Client가 권한을 얻지 못하도록 보장해야 함

Cross-Site Request Forgery(=CSRF): 최종 사용자의 User-Agent가 악의적인 URI를 따라 신뢰된 서버로 요청을 보내도록 유도하는 공격 기법. 이때의 신뢰된 서버는 유효한 세션, 쿠키가 존재해 사용자가 이미 인증된 상태로 간주

---

13. Clickjacking

• Clickjacking 공격이 이루어지면 Resource Owner의 인지나 동의 없이 접근 권한 등을 획득 가능하다.

• 공격 방지를 위해 Native Application은 권한 부여 요청할 때 Embedded Browser(Software 내 브라우저) 대신 External Browser(OS에 설치된 별도 브라우저) 사용

• 비표준 헤더인 X-Frame-Options 헤더 설정

- X-Frame-Options: deny
ㄴ 어떤 사이트에서도 frame 허용 금지

- X-Frame-Options: sameorigin
ㄴ 같은 origin의 사이트에서만 frame 허용

Clickjacking: 공격자가 iframe 혹은 css를 사용해 정상 페이지 위로 투명한 악성 페이지 구현. 사용자의 클릭을 유도해 공격 수행 가능

Embedded Browser(내부 브라우저): Native Application 내부에 <WebView> 컴포넌트 직접 포함해 웹 페이지 렌더링.

• 보안 UI 없거나 제한적 제공
• 일부 보안 헤더 해석되지 않음
• 호스트 Application 프로세스 내에서 동작. Application 코드, 권한 영향권 내에 제어 조작 위험 존재

External Browser(외부 브라우저): OS가 기본으로 제공하거나 사용자가 설치한 독립 실행형 브라우저 Application

• 브라우저 보안 UI 제공
• 보안 헤더 동작
• Application과 분리된 프로세스. Application 취약점으로부터 세션 격리

---

14. Code Injection & Input Validation

• 입력 또는 기타 외부 변수가 Application에 의해 비정상적으로 사용, Application 로직을 수정할 때 발생

• 공격자가 Application 장치, 데이터에 접근 혹은 Dos 유발 등 광범위한 악성행위 허용

• Authorization Server와 Client는 수신된 모든 값, 특히 state 및 redirect_uri 파라미터 값을 sanitize 및 유효성 검사 필요

---

15. Open Redirectors

• Authorization Server, Authorization Endpoint, Client Redirection Endpoint는 부적절하게 구성되어 Open Rediractors로 작동 가능

• Open Redirectors는 Phishing Attacks에 사용되거나 최종 사용자를 악성 사이트로 방문 시킬 수 있음

• 또한 Authorization Server가 Client에게 Redirection URI의 부분 매칭을 허용할 경우 Authorization Code, Access Token 등을 공격자가 제어하는 Endpoint로 전송 가능

Open Redirectors: Web Application이 외부에서 받은 Redirection URL 파라미터를 검증 없이 신뢰하여, 사용자 브라우저를 임의의 외부 사이트로 Redirection 시키는 취약점

---

16. Implicit Flow에서 Resource Owner 사칭을 위한 Access Token 오용

• Implicit Flow을 사용하는 공용 Client의 경우 Access Token을 발급한 Client를 Client 자체적으로 확인할 방법을 제공하지 않음

• Resource Owner가 Phising등의 이유로 악성 Client에게 Access Token 부여 혹은 공격자가 다른 수단을 통해 토큰 탈취 가능

• 공격자는 탈취한 Access Token을 정상적인 공개 Client에 제공함으로써 Resource Owner 사칭 시도 가능

• Implicit Flow에선 공격자가 Authorization Server로부터 되돌아오는 응답에서 공격자의 토큰으로 swap 가능

• Back Channel로 Access Token을 전달받아 사용자 식별하는 Native Application과 통신하는 Server도 유사하게 위협 가능

• Resource Owner만이 자신의 Resource에 대한 Access Token을 제공 가능하다 가정하는 모든 공개 Client는 해당 공격에 취약

• 상기한 유형의 공격은 Client에서 Resource Owner에 대한 정보를 공격자에게 노출 가능

• 또한 공격자는 Access Token 또는 Authorization Code를 부여한 Resource Owner와 동일한 권한으로 Client에서 작업 수행 가능

• OAuth를 사용자 인증 수단으로 쓰기 위해선 Access Token이 자체 사용을 위해 발급되었는지 Client가 확인 가능한 추가 보안 메커니즘 없이 Implicit Flow를 사용해서는 안됨

Implicit Flow(암시적 흐름): Client Secret을 안전하게 보관 불가능한 환경에서 Authorization Code 단계를 건너뛰고 Access Token을 바로 전달받는 흐름