OAuth2.0 SNS Login (Authorization Code Grant)

로그인 변화

ID, PWD 체크

• ID, PWD을 Request에 보낸 후 ID, PWD을 DB에 저장된 값과 비교
• 단점 : 중요정보을 포함하는 것 자체가 위험하며, 매번 인증 절차가 필요

Session, Cookie

• 매번 ID, PWD 중요정보를 전달하는 게 부담스럽고 불필요하니 최초 로그인된 정보와 유니크한 Key을 매칭 시켜 제공하는 Session이 등장
• 단점 : Session이 유출되면 어떻게하니?

토큰 인증 JWT(Json Web Token) / JOT..?

• Header, Playload(데이터), Verify Signature + Secret key로 서명하여 Access Token을 생성
• Secret key 모르면 복호화를 할 수가 없음
• 단점 : AccessToken이 유출되면?? Expire 될 때까지 다 쓸 수 있잖아???

Refresh Token 등장

• Access Token이 유출됐다고 가정하면. Access Token이 짧을수록 Access Token을 사용할 수 있는 기회가 짧아진다.
• 그래서 Access Token의 유효시간을 짧게 한 후 Expire 되면 Refresh Token으로 새로운 Access Token을 생성하도록 한다.

용어

• Resource Owner : 저스틴 (사용자)
• Client : 티스토리 OPEN API
• Authorization Server : 권한을 관리하는 서버입니다. Access Token, Refresh Token을 발급, 재발급해주는 역할을 합니다
• Resource Server : OAuth 2.0을 관리하는 서버(Google, Facebook, Naver 등) 의 자원을 관리하는 서버입니다.

OAuth1.0, OAuth2.0 차이

인증절차 간소화

• OAuth1.0은 디지털 서명 기반이었지만 OAuth 2.0은 HTTPS을 사용해서 단순화했다.

용어 변경

• 사용자 : Resource Owner <-> User
• REST API : Resource Server <-> Protected Resource
• 인증서버 : Authorization Server <-> Server Provider
• 써드 파트 애플리케이션 : Client <-> Service Provider

Respource Server와 Authorization Server분리

#인증 방식(Grant Type)

• Authorization Code Grant
• Implicit Grant
• Resource Owner Password Credentials Grant
• Client Credentials Grant
• Device Code Grant
• Refresh Token Grant

Authorization Code Grant

• 정의
  • 일반적인 웹사이트에서 소셜 로그인과 같은 인증을 받을 때 가장 많이 쓰는 방식
  • Client가 다른 사용자 대신 특정 리소스에 접근을 요청할 때 사용된다.
  • ID, PWD을 통해 받은 Authorization Code을 이용해 최종적인 Access Token을 발급받아 사용한다.
• 순서
  1. 저스틴(Resource Owner)이 티스토리(Client)에 인증을 요청한다.
  2. 티스토리(Client)는 Authorization Request를 통해 저스틴(Resource Owner)에게 인증할 수단(ex Facebook, Google 로그인 url)을 보냅니다.
     1. response_type : Code
     2. clienrt_id : 티스토리(Client) 식별자로 미리 등록하여 부여받아야 된다.
     3. rediret_uri : 인증이 완료 됐을 때 이동시킬 페이지 주소
     4. scope : 어떤 범위까지 권한을 요청할 것인가? 자세한 권한 정보는 Authorization Server가 보유하고 있습니다.
     5. state : 커스텀 파라미터로 Authorization Server을 오고 갈 때 함께 전달할 값.
  3. 저스틴(Resource Owner)은 해당 Request를 통해 인증(로그인)을 진행하고 인증을 완료했다는 신호로 Authorization Grant를 url에 실어 티스토리(Client)에게 보냅니다.
     1. code(Authorization code), state값을 추가하여 전달한다.
     2. Authorization code는 Access Token을 구하기 위해 일회성으로 필요함
  4. 티스토리(Client)는 해당 권한 증서(Authorization Grant)를 Authorization Server에 보냅니다.
     1. grant_type : authorization_code
     2. code : 전달받은 authorization_code
     3. redirect_uri : 인증이 완료 됐을 때 이동시킬 페이지 주소
     4. client_id or client_secret : 티스토리(Client) 인증이 필요하므로 client_id 필요
  5. Authorization Server는 권한 증서를 확인 후, 유저가 맞다면 티스토리(Client)에게 Access Token, Refresh Token, 그리고 유저의 프로필 정보(id 포함) 등을 발급해줍니다.
     1. access_token :
     2. token_type : 액세스 토큰의 타입
     3. expires_in : 액세스 토큰의 유효기간 (단위 Seconds)
     4. refresh_token : 추후 새로운 액세스 토큰을 발급받을 때 필요한 토큰
     5. scope :
  6. 저스틴(Client)은 해당 Access Token을 DB에 저장하거나 저스틴(Resource Owner)에게 넘깁니다.
  7. 저스틴(Resource Owner)이 Resource Server에 자원이 필요하면, 티스토리는(Clien) t는 Access Token을 담아 Resource Server에 요청합니다.
  8. Resource Server는 Access Token이 유효한지 확인 후, 티스토리(Client)에게 자원을 보냅니다.

     8-1. 만일 Access Token이 만료됐거나 위조되었다면, 티스토리(Client)는 Authorization Server에 Refresh Token을 보내 Access Token을 재발급받습니다.

  9. 그 후 다시 Resource Server에 자원을 요청합니다.
  10. 만일 Refresh token도 만료되었을 경우 다시 로그인을 하도록 합니다.

 

다이어그램

인증 Flow

 

 

페이스북 설정

facebook developers 

facebook develope 기본설정

 

redirect url 설정

 

 

 

 

 

 

 

참고

https://widecode.tistory.com/5?category=696402
https://tansfil.tistory.com/60