OAuth란? (OAuth2.0)

개념

인터넷 사용자들이 비밀번호를 제공하지 않고 다른 웹사이트 상의 자신들의 정보에 대해 웹사이트나 애플리케이션의 접근 권한을 부여할 수 있는 공통적인 수단으로서 사용되는, 접근 위임을 위한 개방형 표준

• OAuth 사용 전에는 인증 방식의 표준이 없어 기본 인증인 아이디와 비밀번호 사용 -> 보안상 취약한 구조
• 기본 인증이 아닐 경우, 각 애플리케이션이 각자 개발한 회사의 방법대로 사용자 확인
  ex) 구글 AuthSub, AOL OpenAuth, 야후 BBAuth, 아마존 웹서비스 API
• 이렇게 제각각인 인증방식을 표준화한 인증 방식
• OAuth 이용하면 이 인증을 공유하는 애플리케이션끼리는 별도의 인증 불필요 -> 여러 애플리케이션을 통합하여 사용하는 것이 가능하게 됨
• OAuth 2.0은 1.0에서 알려진 보안 문제 등을 개선한 버전

 

구성 및 종류

구성

• 리소스 소유자 : API에 대한 권한을 가지고 있으며, 이를 위임할 수 있는 이용자
• 보호된 리소스 : 리소스 소유자가 접근하는 대상
• 클라이언트 : 리소스 소유자를 대신해 보호된 리소스에 접근하는 소프트웨어 등
• 인가 서버 : 리소스에 접근할 수 있는 접근 토큰을 발급

 

프로토콜 종류

종류(Type)	설명
인가 코드 승인 (Authorization Code Grant)	클라이언트가 다른 사용자 대신 특정 리소스에 접근을 요청할 때 사용 리스소 접근을 위해, 인가 서버에서 받은 권한 코드로 리소스에 대한 엑세스 토큰을 받는 방식
암묵적 승인 (Implicit Grant)	권한 부여 코드 승인 타입과 다르게 권한 코드 교환 단계가 없음 엑세스 토큰을 즉시 반환받아 이를 인증에 이용하는 방식
리소스 소유자 암호 자격 승인 (Resource Owner Password Credentials Grant)	클라이언트가 암호를 사용하여 엑세스 토큰에 대한 사용자의 자격 증명을 교환하는 방식
클라이언트 자격 승인 (Client Credentials Grant)	클라이언트가 컨텍스트 외부에서 액세스 토큰을 얻어 특정 리소스에 접근을 요청할 때 사용하는 방식

 

OAuth1.0 vs OAuth2.0

	OAuth1.0	OAuth2.0
참여자	- 이용자 - 소비자 - 서비스 제공자	- 자원 소유자 - 클라이언트 - 권한 서버 - 자원 서버
토큰	- 요청 토큰(Request Token) - 접근 토큰(Access Token)	- 접근 토큰(Access Token) - 재발급 토큰(Refresh Token)
유효기간	- 접근 토큰의 유효 기간이 없음	- 접근 토큰 유효기간 부여 - 만료 시 재발급 토큰 이용
클라이언트	- 웹 서비스	- 웹, 앱 등

 

구성요소

Resource Owner

• 웹 서비스를 이용하려는 유저, 자원(개인정보)을 소유하는 자, 사용자
• 요청하고자 하는 자원의 소유자이자, 인증 주체
• ex) 이용자

Client

• 자사 또는 개인이 만든 애플리케이션 서버
• 자원을 필요로 하는 서비스
• 자원 소유자의 권한으로 권한 서버에서 인증을 받아 자원 서버에 자원 요청
• ex) 쇼핑몰 등

Authorization Server

• 인증을 처리하고 권한을 부여해주는 서버
• 사용자는 이 서버로 ID, PW를 넘겨 Authorization Code를 발급 받을 수 있음
• Client는 이 서버로 Authorization Code를 넘겨 토큰을 발급 받을 수 있음
• ex) 페이스북, 네이버, 구글, 카카오 등

Resource Server

• 사용자의 개인정보를 가지고 있는 애플리케이션(구글, 페이스북, 네이버, 카카오 등) 회사 서버
• Client는 토큰을 이 서버로 넘겨 개인정보를 응답받을 수 있음
• 자원을 가지고 있는 서버
• ex) 페이스북, 네이버, 구글, 카카오 등

Access Token

• 자원에 대한 접근 권한을 Resource Owner가 인가하였음을 나타내는 자격증명
• 자원 서버에 자원을 요청할 수 있는 토큰

Refresh Token

• Client는 Authorization Server로부터 access token과 refresh token을 함께 부여받음
• access token은 보안상 짧은 만료기간이 지나면 사용자는 다시 로그인 해야하지만, refresh token이 있다면 access token 만료 시 refresh token을 통해 access token을 재발급 받아 다시 로그인 할 필요가 없음
• 권한 서버에 접근 토큰을 요청할 수 있는 토큰

 

인증방식

1. 사용자는 특정 애플리케이션에서 OAuth 서비스를 요청한다.
2. 애플리케이션(Client)에서는 OAuth 서비스에 Authorization Code를 요청한다.
3. OAuth 서비스는 Redirect를 통해 Client에게 Authorization Code를 부여한다.
4. Client는 Server에게 OAuth 서비스에서 전달받은 Authorization Code를 보낸다.
5. Server는 Authorization Code를 다시 OAuth 서비스에 전달해 Access Token을 전달받는다.
6. Server는 Access Token으로 Client를 인증하고 요청에 대한 응답을 반환한다.

---

[참고자료]

https://ko.wikipedia.org/wiki/OAuth

OAuth - 위키백과, 우리 모두의 백과사전

https://tecoble.techcourse.co.kr/post/2021-07-10-understanding-oauth/

OAuth 개념 및 동작 방식 이해하기

https://hwannny.tistory.com/m/92

OAuth 2.0 개념 정리

https://inpa.tistory.com/m/entry/WEB-%F0%9F%93%9A-OAuth-20-%EA%B0%9C%EB%85%90-%F0%9F%92%AF-%EC%A0%95%EB%A6%AC

[WEB] 📚 OAuth 2.0 개념 정리 (그림으로 이해하기 쉽게)

https://itwiki.kr/w/OAuth

IT위키

https://velog.io/@undefcat/OAuth-2.0-%EA%B0%84%EB%8B%A8%EC%A0%95%EB%A6%AC

[OAuth 2.0] OAuth란?

https://doqtqu.tistory.com/m/295

[OAuth] OAuth2.0란?

https://www.ssemi.net/what-is-the-oauth2/

OAuth 란 무엇인가?

https://pronist.dev/m/144

OAuth 2.0 소셜 로그인 구현하기(feat. 깃허브)

https://about-tech.tistory.com/m/entry/Security-OAuth-20%EB%9E%80-%EA%B0%9C%EB%85%90-%EC%9D%B8%EC%A6%9D%EB%B0%A9%EC%8B%9D