OAuth 2.0 서버 설계시 고려사항 정리

OAuth 2.0 사용 여부 결정

• API 서버 설계시 가장 먼저 고려할 점은 클라이언트에게 1개 이상의 인증 방법을 제공할 수 있어야 한다. 대표적으로 OAuth 2.0과 API Keys(Basic Auth) 방식이 존재한다.





• 클라이언트가 API 서버에 요청하는 데이터가 특정 사용자와 무관한 공개적 성격(지도, 날씨 등)을 가진다면 OAuth 2.0을 사용하지 않고 api_key, api_secret를 발급하는 것으로 충분하다. 단지 요청이 유효한 클라이언트인지를 식별해주는 역할을 수행한다.




• 하지만 데이터가 특정 사용자와 연관된 개인적 성격(특정 사용자의 동의가 필요한 개인 데이터 등)을 가진다면 OAuth 2.0을 사용해야 하므로 client_id, client_secret을 발급해야 한다. [관련 링크]

api_key 사용시 고려할 점

• 클라이언트 입장에서 api_key를 이용한 요청 방법은 간단한다. 매 요청마다 Basic {api_key}:{api_secret} 문자열을 base64 인코딩하여 요청 헤더의 Authorization 헤더에 담으면 된다. 커스텀 헤더에 담지 않고 Authorization 헤더에 담는 것은 Basic Auth 표준을 준수하면서 프록시 서버에 캐시로 저장되는 것을 예방하는 효과도 있다. 요청은 반드시 HTTPS 프로토콜로 전송되어야 한다.



• api_key 발급시 보안을 위해 api_secret은 발급 당시 최초 1번만 노출되어야 한다. api_secret을 분실했다면 재발급을 요청하면 된다. 재발급이 이루어지면 전에 사용하던 api_key는 24시간만 유효하게 된다. [관련 링크]



• 클라이언트는 발급된 api_key를 절대 소스 코드(파일)에 노출하면 안된다. 환경변수 등에 저장하는 방법으로 은닉해야 한다. [관련 링크]


• API Key의 보안을 강화하는 방법으로는 서버 측에서 요청이 허용되는 IP 주소, 참조 URL 등의 제약을 설정하는 방법이 있다.


• 불필요한 외부로부터의 공격을 예방하기 위해 사용하지 않는 API Key는 삭제해야 한다.

OAuth 2.0 인증 정보의 획득

• API 서버에 저장된 사용자(End User)의 정보를 사용하려는 클라이언트는 서버 측에 OAuth 2.0 Credential을 요청해야 한다.


• OAuth 2.0 Credential은 client_id와 client_secret로 구성된다. 추가적으로 API 서버에서 사용자 인증 후 결과를 리다이렉트할 redirect_uri가 필요하다.


• OAuth 2.0 사용의 장점은 사용자 → 클라이언트 → 서버 구조에 있어 사용자의 중요한 인증 정보가 클라이언트에게 노출될 일이 없다는 것이다. 클라이언트는 미리 서버로부터 발급 받은 client_id, client_secret으로 서버에 사용자의 로그인과 정보 사용 동의를 요청하며 서버는 사용자 인증 후 클라이언트에게 일시적으로만 접근이 유효한 access_token을 발급함으로서 중요 정보의 노출 없이 API 서버(Resource Server)의 정보를 사용할 수 있게 해준다. [관련 링크]

OAuth 2.0 인증과 권한

• OAuth 2.0은 얼핏 복잡하고 어려워 보이지만 핵심은 인증(Authentication)과 권한(Authorization)이라고 할 수 있다.


• 인증은 이 클라이언트가 사용자의 데이터를 사용해도 되는지 여부를, 권한은 어떤 데이터를 사용할 수 있는지를 가리킨다.


• 권한은 scope로 표현된다. 하나의 엔드포인트(Endpoint)를 실행하기 위해서는 1개 이상의 scope(ex: read:current_user, read:users)를 필요로 한다. 각 클라이언트마다 고유의 허가된 scope 배열이 권한 저장소에 저장되어 있다.

참고 글

• How To Control User Identity Within Microservices
• API Security: Deep Dive into OAuth and OpenID Connect
• Why I Love Basic Auth