OAuth2란
등장 배경
1. 암호 인증
- 제3자 애플리케이션이 리소스 소유자에게 보완 취약점의 위험을 감수하고 암호 인증을 진행했다.
2. 접근 범위 및 기간 설정 불가
- 리소스 접근 범위를 특정할 수 없어 광범위한 범위 제공
- 기간을 설정 불가 및 접근 취소 불가
OAuth란?
Open Authorization 2.0 혹은 OAuth2.0은 웹 및 애플리케이션 인증 및 권한 부여를 위한 개방형 표준 프로토콜이다.
이 프로토콜에서는 third-party 애플리케이션이 사용자의 리소스에 접근하기 위한 절차를 정의하고
서비스 제공자의 API를 사용할 수 있는 권한을 부여한다.
대표적으로 구글 로그인과 같은 소셜 미디어 간편로그인이 많이 사용한다.
역할
리소스 소유자
보호된 리소스를 소유한 사용자, 간단히 말해서 유저를 말한다.
클라이언트
OAuth 2.0을 사용하여 리소스에 접근하려는 서비스, 간단히 말해서 우리 서비스 서버를 말한다.
권한 서버
클라이언트가 리소스 소유자의 권한을 얻을 수 있도록 도와주는 서버
사용자 인증, 권한 부여 및 토큰 발급을 관리한다.
리소스 서버
보호되는 리소스를 호스팅하는 서버로, 액세스 토큰으로 접근을 허용 ,실제 데이터 를 제공한다.
네이버 , 깃 , 구글과 같은 사용자 리소스 데이터를 갖고 있는 서버들을 말한다.
과정

1. register
OAuth 2.0 Playground
OAuth 2.0 Playground The OAuth 2.0 Playground will help you understand the OAuth authorization flows and show each step of the process of obtaining an access token.
www.oauth.com
위 사이트를 통해 OAuth 2.0 과정을 밞아 보자.

우리 서비스를 등록한다. 만약 네이버 로그인을 사용하면 네이버에, 구글 로그인을 사용하면 구글에 다음과 같은
과정을 진행한다.
여기서 중요한 점은 우리는 등록 과정에 총 3가지를 얻는다.
- redirect_url
- 로그인 성공한 후 이동될 url을 등록한다.
- client_id
- 우리 서비스를 구분할 id값으로 외부로 공개되어도 상관이 없다.
- 엑세스 토큰을 얻는데 필요하다.
- client_secret
- 절대 외부로 공개되어서는 안된다.
- 엑세스 토큰을 얻는데 필요하다.
2. 로그인 요청
유저(리소스 오너)가 우리 서비스를 소셜 로그인을 통해 로그인 하기위해 로그인 버튼을 누른 상황이다.
Authorization Server에게 response_type , client_id , redirect_uri , scope 등의 매개변수를 쿼리 스트링으로 포함하여 보낸다.
- response_type : 반드시 code 로 값을 설정해야한다.
- client_id : 애플리케이션을 생성했을 때 발급받은 Client ID
- redirect_uri : 애플리케이션을 생성할 때 등록한 Redirect URI
- scope : 클라이언트가 부여받은 리소스 접근 권한 , 범위 등을 나타낸다. 아래 사진에서 photos에 해당된다.
curl -X GET https://authorization-server.example.com/oauth/authorize
?response_type=code
&client_id=your_client_id
&redirect_uri=your_redirect_uri
&state=your_state
&scope=your_scope

3. 로그인 시도
Authorization URL로 이동하여 유저(리소스 오너)는 제공된 로그인 페이지에서 로그인을 한다.
4. 인증 코드 전달
로그인을 성공하면 인증 서버로 등록한 redirect URL로 사용자를 이동 시킨다.
이 때 redirect URL에 Authorization Code(인증 코드)를 실어 본낸다.
Authorization Code는 추후 Access Token을 얻기위한 임시 발급 코드다.
보통 1 ~ 10분 정도의 수명을 갖고 있다.

사진을 보면 redirect URL에 code 값이 전달되는 걸 확인할 수 있다.
5. 엑세스 토큰 발급
위 과정에서 얻은 Authorization Code, client_id, client_secret을 보내 acces_token과 refresh_token을 얻어온다.
POST /oauth/token HTTP/1.1
Host: authorization-server.com
grant_type=authorization_code
&code=xxxxxxxxxxx
&redirect_uri=https://example-app.com/redirect
&client_id=xxxxxxxxxx
&client_secret=xxxxxxxxxx
7. 리소스 접근
Resource Owner가 Resource Server의 리소스가 필요한 기능(예: 사진) 을 Client 서버에 요청한다.
Client 서버는 위 과정에서 발급받고 저장해둔 Resource Owner의 Access Token을 사용하여 제한된 리소스에 접근하고,
Resource Owner에게 자사의 서비스를 제공한다.
토근
Access token
리소스 서버에서 보호된 리소스에 접근하기 위한 인증토큰
보통 기간이 짧다.
Refresh token
엑세스 토큰이 만료되었을 때 새로운 액세스 토큰을 발급받기 위한토큰
유효 기간이 상대적으로 길어 클라이언트가 다시 로그인할 필요 없이 접근을 연장할 수 있다.
참고
https://guide.ncloud-docs.com/docs/b2bpls-oauth2