- OAuth = token 발급
- OAuth에는 3개의 객체가 존재한다.
1. 역할
▼ User - mine - Their
▼ OAuth에서 불리는 역할 명
- User = Resource Owner : 자원을 가지고 있는 소유자
- mine = Client : Resouce Server에 접속해서 정보를 가져가는 자
- Thier = Resource Server : 우리가 갖고 있는 자원을 갖는 서버
+ Authorization Server : 인증과 관련된 처리를 전담하는 서버
2. 등록; Register
- Client가 Resource Server을 접속하기 위해선 Resource Server의 승인을 사전에 받아야 한다.
☞ 이것을 '등록' 이라고 한다 !
※ 서비스마다 등록방법이 다르지만 공통적인 부분은 다음과 같다
Client ID : 만든 애플리케이션을 식별하는 ID → 노출되도 상관없음
Client Seceret : ID의 비밀번호 → 외부에 노출되면 X
Authorized redirect URLs : Resource Server가 권한을 부여하는 과정에서 Authorized Code를 전달받으면 주소를 알려준다.
3. Resource Server 승인
- 등록 후
Client는 id와 secret을 얻고, 동시에 Resource Server는 Client id와 secret, redirect URL을 얻는다.
★ Client가 Resource Server에서 일부 기능만 필요하다면, 모든 기능의 인증을 하지 않고 필요한 인증만 하면 된다.
▶ 승인절차
- Resource Owner(User)는 Application에 접근을 한다.
- 만약 글을 쓰거나 날짜를 기록하는 등 Resource Server의 기능을 필요로 한다면, Client는 Resource Owner에게 Resource server를 제공한다.
(1) Resource Owner가 Resource Server에 https://~ 주소로 접속을 하면 Resource server는 owner가 로그인이 되어 있는지 확인
(2) 로그인이 되어 있지 않을 경우, server는 owner에게 로그인하라는 화면 제공
(3) owner가 로그인 성공 후, server는 client id와 같은 id값이 있는지 확인
→ 해당 client id의 url과 접속하고자 하는 url값과 다르면 종료,
→ 같다면 owner에게 scope에 해당하는 권한을 client에게 부여할 것인지 전송
(4) 허용한다면 server는 user id와 해당 scope을 저장한다.
4. Resource Owner 승인
(1) server가 owner에게 Authorization code(임시 비밀번호)가 포함된 주소를 owner에게 전송
(2) owner는 server에게 받은 주소로 접속하면 client는 authorization code 값을 받는다.
(3) client는 server에 직접 접속
→ server는 client에게 받은 authorization code값과 client id, secret이 일치하는 확인
→ 일치할 경우, Access token을 발급한다.
5. 액세스 토큰 발급
▶ server는 인증된 authorization code를 모두 지움(client 포함)
why? 이미 인증했기 때문에 다시 인증을 하지 못하도록 하기 위해)
→ server는 client에게 Access Token을 발급
→ client는 token을 저장
☞ 나중에 client가 access token으로 server에 접속하게 되면, server는 해당 access token이 가진 client id의 유효한 기능 scope을 허용하게 된다.
6. API 발급
- API; Application Programming Interface
= client는 resource server를 호출해서 어떠한 일들을 하게 되는데, 이때 server를 호출하는 접근 장치를 API 라고 한다.
