1. OAuth가 뭔가요
OAuth(Open Authorization)는 인터넷 사용자들이 비밀번호를 제공하지 않고 다른 웹사이트 상의 자신들의 정보에 대해 웹사이트나 애플리케이션의 접근 권한을 부여할 수 있는 공통적인 수단으로서 사용되는, 접근 위임을 위한 개방형 표준이다. 이 매커니즘은 여러 기업들에 의해 사용되는데, 이를테면 아마존, 구글, 페이스북, 마이크로소프트, 트위터가 있으며 사용자들이 타사 애플리케이션이나 웹사이트의 계정에 관한 정보를 공유할 수 있게 허용한다.
- wikipedia
요즘은 '카카오톡으로 로그인하기' 'Google로 시작하기' 와 같은 다른 계정을 통해서 회원가입 및 로그인할 수 있는 서비스들이 많다. 타 서비스의 계정을 기반으로한 인증 기능을 사용하면 회원가입 flow나 로그인을 위한 비밀번호 관리가 간편해지고, OAuth를 제공하는 회사와 연동되는 서비스를 사용할 수 있기 때문에 많이 사용하고 있는데 바로 이 기능이 OAuth이다.
즉, 정리하자면 OAuth는 인증을 위한 오픈 스탠더드 프로토콜로, 사용자가 Facebook이나 트위터 같은 인터넷 서비스의 기능을 다른 애플리케이션(데스크톱, 웹, 모바일 등)에서도 사용할 수 있게 한 것이다.
OAuth를 제공하는 회사는 본인들의 영역을 넓힐 수 있고, OAuth를 사용하는 회사는 비밀번호 관리에 대한 번거로움과 유저 이탈없이 로그인을 유도할 수 있다는 장점이 있다.
OAuth2.0
물론 처음에는 OAuth가 없었고 각 회사마다 각자의 인증 방식을 가지고 있었다. (ex. 구글의 AuthSub, AOL의 OpenAuth, 야후의 BBAuth, 아마존의 웹서비스 API 등) 각자 다르게 구현된 인증 방식을 표준화한 것이 OAuth이다.
우리가 지금 사용하는 OAuth는 2.0 버전인데 숫자에서 짐작할 수 있듯이 1.0도 존재한다. OAuth 1.0은 2010년 공식 포준안 RFC 5849로 발표되었지만 인증 절차가 복잡하고, 모바일 애플리테이션에 대한 지원이 부족했으며 인증을 위한 AccessToken이 만료되지 않아서 보안적으로 취약했다.
이를 보완한 OAuth2.0이 2012년에 발표되었다(RFC 6749). OAuth1.0과 OAuth2.0은 호환되지 않으며 나는 OAuth2.0를 기준으로 공부 + 구현했기 때문에 이 글에서는 OAuth 2.0에 대한 이야기를 하려한다.
1. OAuth2.0 에 존재하는 4가지 Role
| Resource Owner |
리소스 소유자 또는 사용자. 보호된 자원에 접근할 수 있는 자격을 부여해 주는 주체. |
| Client | 보호된 자원을 사용하려고 접근 요청을 하는 애플리케이션. |
| Resource Server |
리소스 소유자의 데이터를 관리하는 서버. |
| Authorization Server | 권한 서버. 인증/인가를 수행하는 서버로 클라이언트의 접근 자격을 확인하고 Access Token을 발급하여 권한을 부여하는 역할을 수행. |
※ 여기서 말하는 클라이언트가 우리가 흔히 생각하는 프론트를 의미하는 클라이언트가 아님을 유념하도록 하자!!!!
2. OAuth2.0 Flow
- A : 클라이언트가 리소스 소유자에게 인증을 요청한다.
- B : 리소스 소유자는 계정 로그인을 통해서 인증을 허가한다.
- C : 리소스 소유자가 동의를 했음을 인증 서버에 알린다.
- D : 인증 서버는 클라이언트에게 Access Token을 발급한다.
- E : 클라이언트는 발급받은 Access Token을 사용하여 리소스 서버에 데이터를 요청한다.
- F : 엑세스 토큰이 유효하다면 클라이언트에게 리소스 소유자의 데이터를 제공한다.
OAuth 2.0 프레임워크는 어플리케이션을 승인한 사용자에 대한 정보를 명시적으로 제공하지 않고, 액세스 토큰(Access Token)이라는 형태로 권한을 제공한다. 액세스 토큰은 마치 호텔 키 카드와 같아서 카드키만으로는 카드키 소유자가 어떤 객실에 출입할 권한이 있는지 알 수 있지만, 카드키 소유자에 대한 신원 정보는 알 수 없다.
3. OAuth2.0 권한 부여 방식
3.1. Authorization Code Grant, 권한 부여 승인 코드 방식
권한 부여 승인을 위해 자체 생성한 Authorization Code를 전달하는 방식으로 많이 쓰이고 기본이 되는 방식
간편 로그인 기능에서 사용되며 클라이언트가 사용자를 대신하여 특정 자원에 접근을 요청할 때 사용한다. 보통 타사의 클라이언트에게 보호된 자원을 제공하기 위한 인증에 사용한다. Refresh Token의 사용이 가능하다.
권한 부여 승인 요청 시 response_type을 code로 지정하여 요청하고, 클라이언트는 권한 서버에서 제공하는 로그인 페이지를 브라우저를 띄운다. 이 페이지를 통해 사용자가 로그인을 하면 권한 서버는 권한 부여 승인 코드 요청 시 전달받은 redirect_url로 Authorization Code를 전달하고 클라이언트는 권한 서버에서 제공하는 API를 통해 Code를 Access Token으로 교환받는다.
3.2. Implicit Grant, 암묵적 승인 방식
자격증명을 안전하게 저장하기 힘든 클라이언트(ex: JavaScript등의 스크립트 언어를 사용한 브라우저)에게 최적화된 방식
권한 부여 승인 코드 없이 바로 Access Token이 발급된다. Access Token이 바로 전달되므로 만료기간을 짧게 설정하여 누출의 위험을 줄여야 한다. Refresh Token 사용이 불가능하다.
이 방식에서 권한 서버는 client_secret를 사용해 클라이언트를 인증하지 않는다. Access Token을 획득하기 위한 절차가 간소화되기에 응답성과 효율성은 높아지지만 Access Token이 URL로 전달된다는 단점이 있다.
권한 부여 승인 요청 시 response_type을 token으로 설정하여 요청하고, 클라이언트는 권한 서버에서 제공하는 로그인 페이지를 브라우저를 띄워 출력한다. 로그인이 완료되면 권한 서버는 Authorization Code가 아닌 Access Token를 redirect_url로 바로 전달한다.
3.3. Resource Owner Password Credentials Grant, 자원 소유자 자격증명 승인 방식
간단하게 username, password로 Access Token을 받는 방식
클라이언트가 타사의 외부 프로그램일 경우에는 이 방식을 적용하면 안된다!! 자신의 서비스에서 제공하는 어플리케이션일 경우에만 사용한다. Refresh Token을 사용할 수 있다.
제공하는 API를 통해 username, password을 전달하여 Access Token을 받는다.
권한 서버, 리소스 서버, 클라이언트가 모두 같은 시스템에 속해 있을 때 사용되어야 하는 방식이라는 것을 잊지말자!!
3.4. Client Credentials Grant, 클라이언트 자격증명 승인 방식
클라이언트의 자격증명만으로 Access Token을 획득하는 방식
OAuth2의 권한 부여 방식 중 가장 간단한 방식으로 클라이언트 자신이 관리하는 리소스 혹은 권한 서버에 해당 클라이언트를 위한 제한된 리소스 접근 권한이 설정되어 있는 경우 사용된다.
이 방식은 자격증명을 안전하게 보관할 수 있는 클라이언트에서만 사용되어야 하며, Refresh Token은 사용할 수 없다.
4. Bearer 인증
Bearer 인증 방식은 OAuth 2.0 프레임워크에서 사용하는 토큰 인증 방식이다. “Bearer”은 소유자라는 뜻으로 Authorization 헤더에 "Bearer " + 토큰을 담아서 요청을 보낸다.
Authorization: Bearer <token>
사실 Bearer 이라는 문자열 자체는 암묵적 약속 같은 것이기 때문에 클라이언트와 협의만 되었다면 다른 문자열을 넣어서 표기해도 상관은 없다. 하지만 확장 및 유지보수성을 생각했을 때 약속된 틀을 잘 지키는 것이 바람직하다고 생각된다.
4.1. Bearer Token
Bearer 토큰은 OAuth 프레임워크에서 액세스 토큰으로 사용하는 토큰의 유형이다.
Bearer 토큰은 불투명한(Opaque) 문자열로 토큰의 형태는 인증 서버에서 정의하기 나름인데, 16진수의 문자열을 사용하기도 하고 JWT를 사용할 수도 있다.
Bearer 토큰은 클라이언트가 해석할 수 없는 형태여야 하고, 사용자의 정보를 전달하면 안되며 서버에서 클라이언트의 권한을 확인할 수 있는 메타데이터가 토큰에 인코딩되어 있어야 한다. 또한 충분히 복잡한 알고리즘을 사용해서 발급해야 한다.
4.2. Bearer 인증 장점
- 안전하게 리소스를 보호할 수 있다.
- Bearer 토큰은 쉽게 복호화 할 수 없다.
- 서버에서 토큰의 리소스 접근 권한을 쉽게 철회할 수도 있고, 토큰의 유효기간을 설정할 수 있다.
- 확장이 쉽다. (토큰의 장점)
- Bearer 토큰 자체가 메타데이터를 가지고 있어서 서버는 토큰을 발급만 하고 보관할 필요가 없다.
- 사용자가 아무리 많아도 토큰을 검증하는데 같은 시간이 소요된다. 만약 서버에 저장을 한다면 사용자가 많아질수록 조회하는데 시간이 걸릴 것이다.
- 여러 서비스 및 서버 간에 토큰을 공유할 수 있어서 편리하다.
4.2. Bearer 인증 단점
- 만약 Bearer 토큰이 외부에 노출되면 다른 서비스도 토큰으로 바로 리소스에 접근할 수 있다.
- 따라서 OAuth 프레임워크에 정의된 보안 장치를 잘 구축하여 노출되지 않도록 하고, 노출이 발견되면 해당 토큰의 권한을 철회할 수 있도록 구현해야한다.
5. 참고할 것. OAuth와 로그인은 별개로 생각해야 한다.
OAuth 프로토콜은 로그인을 하기 위해 만들어진 것이 아니다.
OAuth, Open Authorization는 클라이언트(타 서비스)가 리소스 서버에서 접근할 수 있는 권한을 관리하는 것이다. 로그인 접근 권한도 그 권한 중에 하나인 것!! 필요에 따라 리소스 소유자가 허용하면 리소스 서버로부터 데이터파일 등 다른 권한도 부여받을 수 있다.
[ 참고 자료 ]
1. 2. OAuth
https://ko.wikipedia.org/wiki/OAuth
https://d2.naver.com/helloworld/24942
3. OAuth2.0 권한 부여 방식
https://blog.naver.com/mds_datasecurity/222182943542
4. Bearer
https://docs.tosspayments.com/blog/everything-about-basic-bearer-auth
https://docs.tosspayments.com/resources/glossary/bearer-auth
'Tech' 카테고리의 다른 글
| Session, JWT (0) | 2024.04.16 |
|---|
댓글