2022. 11. 21. 21:18ㆍ개발공부 기강잡자/Web | HTML&CSS
OAuth 2.0
OAuth(Open Authorization)은 인증을 위한 개방형 표준으로, 웹사이트의 사용자들이 비밀번호를 제공하지 않고, 다른 웹 어플리케이션의 정보에 접근할 수 있도록 하는 접근 권한을 부여한다.
OAuth 기술은 사용자가 트위터나 페이스북 등의 웹서비스를 다른 어플리케이션에서도 사용할 수 있도록 한다.
OAuth 표준이 나오기 전에는 리소스를 제공하는 회사별로 각각 다른 방식으로 인증 방식을 사용했었다. 안전한 인증방식에 대한 논의를 하면서 OAuth 표준이 등장했고 2010년에 OAuth1.0이 발표되었으며, 현재는 OAuth의 구조적인 문제를 해결한 OAuth2.0을 많이 사용하고 있다.
OAuth 인증 방식을 통해 인증(Authentication)과 권한(Authorization)을 획득할 수 있다.
- 인증 : 시스템 접근을 확인하는 것 (로그인)
- 권한 : 행위를 할 수 있는 권리를 확인
예시
우리 서비스가 구글 캘린더에 기록하는 기능을 제공하는 프로그램이라면,
사용자가 우리 서비스에 접속해서 글을 쓰면→ 글을 기반으로 구글 캘린더에 일정을 기록하게 된다.
일정을 기록하기 위해선 Google에 접속하기 위한 사용자의 아이디, 비밀번호 정보가 필요하다
☞ 이때, 사용자가 우리 서비스에 계정 정보를 제공하지 않고 다른 서비스(구글)와 연동가능하도록 하는 것이 OAuth2.0
📍훨씬 더 안전하게 타 서비스와 상호작용 가능해짐
아이디, 비밀번호 대신 accessToken이 제공됨 > 우리의 서비스는 accessToken을 통해 Google 서비스에 엑세스할 수 있다.
Ex) Login with Facebook과 같은 SNS 로그인 서비스
이렇게 별도로 웹사이트 회원가입을 하지 않고, 다른 SNS 계정을 사용해 로그인 할 수 있는 웹페이지도 OAuth 인증을 사용한 것이다.
역할
OAuth2.0에는 3개의 주체가 있다.
- Client (Mine)
: OAuth를 사용하려는 서비스 - Resource Owner (User)
: 서비스를 사용하는 사용자 - Resource Server (Their)
: 데이터를 가지고 있는 서버 (+ Authorization Server : 인증 처리를 전담으로 하는 서버)
OAuth2.0를 사용하기 위한 절차
1. 등록
Client가 다른 애플리케이션의 Resource를 사용하기 위해 Resource Server에 등록부터 해야한다.
Resource Server에 Client를 등록하면 주어지는 정보
- Client ID
: Client의 Application 고유 ID (외부에 노출되어도 됨) - Client Secret
: Client의 Application Password (절대로 노출되어선 안됨) - Authorized redirect URIs
: Resource Server가 권한을 부여하는 과정에서 Client에게 주는 인증 Code를 전달해야하는 인증 URL
(Resource Server는 이 주소가 아닌 다른 주소에서 요청이 오면 그 요청을 무시하게 된다. Client는 이 URL에 해당하는 페이지를 구현하고 있어야 함.)
2. 승인
Resource Server는 Client가 필요로 하는 최소한의 기능에 대해서만 제공한다. 모든 기능에 대해 승인하는 것이 아닌 필요한 기능만 부분적으로 승인한다.
Resource Owner 시점
: Resource Owner가 Client를 사용하면서 Resource Server에 접속해야하는 상황이 발생한 경우에 (ex-페이스북에 게시글 업로드, 캘린더에 일정등록 등)
→ 접근 권한을 요청하는 알림창이 팝업된다. : "~~의 ~~기능을 사용하기 위해서는 다음과 같은 권한이 필요합니다."
→ Client에 접근 권한을 부여하는 것에 Resource Owner가 동의하면(특정 링크에 접속하면)
→ Resource Server는 로그인 하도록 로그인 창을 띄운다.
Resource Server 시점
: Resource Server는 링크의 client_id, uri를 확인
→ 해당 기능을 client가 사용하는 것을 허용하는지 유저에게 동의를 구함
→ 유저(Resource Owner)가 허용함
→ 허용했다는 정보가 Resource Server에게 전달되고, 유저에 대한 접근 권한 동의 정보가 저장됨
AccessToken
방문증과 같다.
만료되기 이전에 AccessToken을 통해 서비스에 접근할 수 있는 권한을 받았다는 증명을 할 수 있는 토큰으로 사용됨
RefreshToken
AccessToken이 만료된 경우, 재발행을 위한 토큰이다.
한번 정리해둔게 날라가버려서 다시 작성했다.🥲
사실 이렇게 개념과 이론만 공부한 것으로는 부족하다. 강의 들은 것을 기반으로 실제로 프로젝트에 적용해보도록 하자..!
참고 :
OAuth2.0 생활코딩
네이버 - OAuth와 춤을 https://d2.naver.com/helloworld/24942