2021-03-15(Mon)

항목	내용
학습 날짜	2021-03-15(월)
학습 시간	11:00~24:00
학습 범위 및 주제	OAuth
학습 목표	트렌센더스 제출전 마지막 체크리스트를 모두 클리어한다.
동료 학습 방법	eunhkim, sanam, jujeong, yohlee와 페어 프로그래밍

상세 학습 내용

OAuth를 다시 활성화시켰는데 우리 발목을 잡는다. 다시 개념을 되새겨보자.

OAuth2

실제 비밀번호 대신 AccessToken이라는 일종의 비밀키를 이용한다.

• AccessToken의 장점

  • 사용자의 실제 비밀번호가 아니다.

  • 서비스의 모든 기능이 아닌 일부 기능만 이용 가능한 토큰이다.

OAuth는 다른 서비스로부터 AccessToken을 얻어내는 기술이다.

OAuth 인증을 위해 필요한 객체

1. User(Resource Owner): 리소스의 주인(일반 사용자)

2. App(client): 제 3자 앱. User가 사용하는 서비스

3. Auth server / Resource server (ex. Google, 42api, github, facebook etc)

   • Resource server: 리소스 저장 서버. API를 통해 리소스를 제공

   • Authorization server: 인증 담당 서버: 인증을 완료하면 access token을 client에게 보낸다.

     • 리소스 서버와 인증 서버는 같은 서버일 수도 있다.

     • 일반적으로 구글이나 페이스북 같은 대규모 서비스에서는 리소스 서버와 인증 서버를 분리한다.

OAuth 로그인을 위해 필요한 요소

OAuth 로그인을 하고자 하는 서비스에서 아래 세 가지 요소를 받아야 한다.

1. Client ID: public key 이다. 공개해도 된다.

2. Client Secret: secret key이다. 공개하면 안 된다. 보통 환경변수에 담아 둔다.

3. Redirect URL: Client ID와 Client Secret을 확인한 후 redirect할 url 주소이다.

OAuth 인증 과정

전제

Client가 Auth Server로부터 Client ID, Client Secret, Redirect URL을 모두 등록/발급 받은 상태여야 한다.

Resource Owner의 승인

• Resource Owner가 Auth Server에게 승인 요청을 보낸다.

• Auth Server가 Resource Owner에게 Authorization Code를 보낸다.

• 이제 Resource Owner가 Client에게 Authorization Code를 보낸다.

• Client는 Client ID, Client Secret, Redirect URL, Authorization Code 네 가지를 모두 갖고 있는 상태이다.

Auth Server의 승인

• 위 네 가지 정보를 Auth Server에 보낸다. (Redirect URL은 optional)

  • redirect_url을 보내는 건 선택이다.

  • 하지만 Client ID, Client Secret, Authorization Code 세 가지는 꼭 보내야 한다.

  • Resource Server는 네 가지 정보가 모두 일치하는지 확인한다.

  • 하나라도 불일치 할 경우 OAuth 로그인은 실패한다.

  • 모두 일치하면 Access Token 을 발급한다.

    • Authorization Code 값은 더 이상 필요없기 때문에 삭제한다.

Access Token 발급

• 발급 받은 Access Token을 통해서 Resource Server의 기능을 이용할 수 있다.

Refresh Token

• Access Token은 cookie처럼 만료 기한이 있다.

• 따라서 만료가 되면 재발급 받아야한다.

• 이 때 사용하는 게 Refresh Token 이다.

• 서비스마다 Refresh Token을 발급하지 않는 경우도 있고 쓰는 방식도 다르다. Access Token은 주로 세션에 저장한다.

  • 만료 기한이 짧다.

• Refresh Token은 중요하기 때문에 DB에 저장한다.

  • 만료 기한이 길다.

우리 프로젝트에서는 아래 관계이다.

• Resource owner: User

• Resource server: 42 api server

• Client: Rails server

참고

Velog 참고

https://ruby-doc.org/stdlib-2.7.2/libdoc/net/http/rdoc/Net/HTTP.html

https://api.intra.42.fr/apidoc/guides/web_application_flow

https://medium.com/@charmiigarg/apigee-introduction-to-oauth-2-0-grant-types-4352aa7aacf7

학습 내용에 대한 개인적인 총평

Authorization code는 잘 받았고, 42api 서버에 Authroization code를 보냈는데 Access Token이 제대로 돌아오지 않았다. 흠 알고보니 42api 문서에 제대로 명시되지 않은 숨겨진 규칙들이 있어서 그런 것이었다. 가령 required 라고 적혀있지 않은 key 값이 사실은 required 라든지.. api 문서가 제대로 적혀있지 않아서 생긴 문제 덕에 시간을 많이썼다. 문서 관리의 중요성을 깨달을 수 있었다.

다음 학습 계획

• 트렌센더스 테스트