OAuth란?

출처 

(제일 도움이 된 글을 빨간색 표시 하였습니다. 읽고 도움이 된 모든 글을 출처로 표기하였습니다. )

https://doqtqu.tistory.com/295

https://www.okta.com/kr/identity-101/whats-the-difference-between-oauth-openid-connect-and-saml/#:~:text=%EA%B0%81%20%ED%91%9C%EC%A4%80%EC%9D%98%20%EC%B0%A8%EC%9D%B4%EC%A0%90,%EC%97%85%EA%B3%84%20%ED%91%9C%EC%A4%80%EC%9D%B4%EB%9D%BC%EB%8A%94%20%EB%8D%B0%20%EC%9E%88%EC%8A%B5%EB%8B%88%EB%8B%A4.

https://velog.io/@jakeseo_me/Oauth-2.0%EA%B3%BC-OpenID-Connect-%ED%94%84%EB%A1%9C%ED%86%A0%EC%BD%9C-%EC%A0%95%EB%A6%AC

https://www.rfc-editor.org/rfc/rfc6749

https://developers.payco.com/guide/development/start

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

 

---

정리

자신이 소유한 리소스에 소프트웨어 애플리케이션이 접근할 수 있도록 허용해 줌으로써 접근 권한을 위임해주는 개방형 표준 프로토콜

그니깐 짧게 말하면, 프로토콜 입니다. 

외부 서비스에서도 인증을 가능하게 하고 그 서비스의 API를 이용하게 해주는 기능을 하는

프.로.토.콜.

인증과 권한 획득하는 용도 로 이 프로토콜을 사용합니다. 

 

 

현재는 OAuth2.0이 많이 사용되고 있다. (OAuth의 세션 고정 공격을 보완한 OAuth 1.0a 를 거쳐서)

1.0 에서는 접근 토큰의 유효기간이 없고, 2.0에서는 유효기간을 부여했네요.

 

 

형보다 나은 아우 ㅋ 

근데 이공계 쪽에서는 언제나 아우가 형보다 낫단 점... 

의미없는 아우란 존재 하지 않는다.

https://m.dongascience.com/news.php?idx=13818

 

이 프로토콜을 구성하는 요소는 아래와 같습니다.

 

1 리소스서버 - 구글 / 네이버 같이 이 프로토콜 서비스를 제공하는 서버

2 리소스오너 - 리소스서버 계정 소유자 (유저)

3 클라이언트 - 개발사, 혹은 내가 만들 클라이언트 앱. 어플리케이션을 의미 

4 권한서버 - 인증하고 토큰 발행하는 서버 (구글 / 네이버의)

5 액세스토큰 - 리소스서버에 리소스 요청을 할 수있는 토큰

6 리프레시토큰 - 권한 서버에 액세스토큰을 요청할 수 있는 토큰 

  +--------+                                           +---------------+
  |        |--(A)------- Authorization Grant --------->|               |
  |        |                                           |               |
  |        |<-(B)----------- Access Token -------------|               |
  |        |               & Refresh Token             |               |
  |        |                                           |               |
  |        |                            +----------+   |               |
  |        |--(C)---- Access Token ---->|          |   |               |
  |        |                            |          |   |               |
  |        |<-(D)- Protected Resource --| Resource |   | Authorization |
  | Client |                            |  Server  |   |     Server    |
  |        |--(E)---- Access Token ---->|          |   |               |
  |        |                            |          |   |               |
  |        |<-(F)- Invalid Token Error -|          |   |               |
  |        |                            +----------+   |               |
  |        |                                           |               |
  |        |--(G)----------- Refresh Token ----------->|               |
  |        |                                           |               |
  |        |<-(H)----------- Access Token -------------|               |
  +--------+           & Optional Refresh Token        +---------------+

               Figure 2: Refreshing an Expired Access Token

(오 이런식으로 문서 쓰는거 멋지네요. 복사도 쉽고... 

액세스토큰이 만료되는 상황을 보여줍니다. 리프레시토큰이 왜 의미가 있나가 위 그림으로 설명이 되네요.1.0 에서는 없던 피쳐라서 중요한 차이점 입니다.)

 

 

 

페이코의 Oauth2.0 인증 과정

실서비스 중에선 이 그림이 깔끔하고 이해하기 쉽더라구요.

페이코, 그리고 페이코의 리소스를 이용하게 되는 서비스 사에서 처리할 부분이 명확해 보여서요.

 

Oauth2.0 인증 과정

위 그림에서 보듯, access token은 서비스에서 자체적으로 저장,관리 함을 알 수 있습니다. 

 

 

이런 식으로 oauth를 사용하는구나~  내가 다루고 저장해야하는 정보는 액세스토큰 정도구나~ 를 깨닫고 급 마무리.  내가 페이코의 idpw를 알 필요없이, 개발할 수 있단 점. 맘에 드네요.