Oauth 2.0

Oauth 2.0 - 여러가지 애플리케이션 기술들(Java, Python, Ruby, PHP 등)을 이용해서 구현

우리가 회원들의 sns정보 (id, 비밀번호) 대신에 Oauth를 통해 sns회사에서 id,비밀번호 대용으로 사용할 수 있는 토큰을 발급해서 해당 sns회사 기능들을 연동해서 사용할 수 있음

토큰(accessToken)
1. 기업에서 accessToken을 발급받아 해당 기업에 접근해 데이터를 전달받고 수정, 삭제가 가능해진다.
2. 회원들의 sns(id, 비밀번호)를 직접 우리가 소유하고 있는것이 아니기 때문에 보안적으로 상당히 유리
3. 우리가 사용하고자 하는 기업입장에서도 해당 기업의 모든 웹 기능들을 부여해주는 것이 아닌 토큰을 통해 우리가 필요한 정보, 기능들만 넘겨줄 수 있기 때문에 기술적 보안으로도 유리
4. 기본적으로 수명이 있다.

• 리소스 서버 : 제어하고자 하는 자원을 갖고 있음

• 리소스 오너 : 자원의 소유자

• 클라이언트 : 리소스 서버에 접속해서 자원을 가져가 활용

  클라이언트가 리소스 서버를 이용하기 위해서는 리소스 서버의 승인을 사전에 받아놔야 함 - 등록

  서비스마다 등록하는 방법은 모두 다름
  하지만 공통적인 것은 Client ID, Client Secret, Authorized redirect URIs 요소를 받음

• Client ID : 우리가 만들고 있는 애플리케이션을 식별하는 식별자 (노출되도 괜찮)

• Client Secret : 해당 식별자의 암호 (노출되면 상당히 위험)

• Authorized redirect URIs : 리소스 서버가 권한을 부여하는 과정에서 우리에게 Autorized Code라는 값을 전달해 줌, 그 때에 해당 주소로 전달해달라는 주소 ( 우리가 Code를 전달받을 주소 )

user id 1번은 해당 리소스 서버의 b, c기능을 활용하는데 동의
리소스 서버는 해당 기능에 대한 유저의 동의를 구했으니 클라이언트는 리소스 서버의 승인을 받아야 함
유저가 제외된 삼자간의 일이기 때문에 문제가 발생하지 않게 하기 위해 리소스 서버는 유저의 웹 브라우저에게 authorization code(가 포함된 Location의 주소)를 발급해줌
해당 주소로 인해 유저의 웹은 클라이언트에게 해당 코드(가 포함된 주소)를 넘겨줌
클라이언트는 유저에게 authorization code를 넘겨받는다.

이로 인해 클라이언트는 authorization code에 대한 리소스 서버에게 요청을 한다.
리소스 서버는 발급해준 해당 code에 대한 Client id, Client Secret 필요한 기능 scope 들을 확인해 일치하는지 확인 후 accessToken을 발급해줌

리소스 서버는 authorization code에 대해 이미 인증을 했기 때문에 해당 코드를 제거

이제서야 클라이언트에게 accessToken을 넘겨주게 된다.

리소스 서버는 클라이언트에게 필요한 기능을 API(Application Programming Interface)를 통해 편하게 사용할 수 있는 방법을 제공해준다.

refresh token
엑세스 토큰은 기본적으로 수명이 있기 때문에 만료가 되면 지금 했던 과정을 다시하기는 번거롭기 때문에 refresh token을 활용
참조 : https://datatracker.ietf.org/doc/html/rfc6749