google cloud credential / api credential / access token
client-side web app 을 위한 OAuth 2.0
OAuth 2.0 은 유저들이 application 과 특정data 를 공유할 수 있게 해준다. 공유하면서도 그들의 user명과 비밀번호와 다른 개인정보를 노출하지 않는다.
예를 들어 OAuth 2.0 은 user의 Google Drive에 file 을 저장하기 위해 그 해당 user로 부터 permission(허락)을 획득하게 된다.
OAuth 2.0 flow 는 implicit grant flow (암묵적 허락 흐름)라고 부른다. 이것은 ’user 가 application 에 있을때만 API들에 접근’하는 application들을 위해 만들어졌다. 이 application들은 기밀정보(confidential information)를 저장해 놓을 수 없다.
me: 그래서 access token 만 처음에 받아와서 사용하게 된다. app 등은 Authorization Code 를 받아온 후에 다시 access token 을 받는다. 다음 글들을 읽어보면 된다. Using OAuth 2.0 for Web Server Applications 를 봐도 알 수 있는데, 이것은 confidential information 을 저장해 놓고 사용하는 app을 위해 design 됐다고 나와 있다.
- What is the OAuth 2.0 Authorization Code Grant Type? | Okta Developer
- Implementing the authorization code grant type | Apigee | Google Cloud 의 diagram
동작
이 flow에서, app 은 query parameter를 이용하는 Google URL 을 연다. 이 query parameter 는 app 을 구별하고, app 이 필요한 API 접근의 종류를 구별하는 값을 갖고 있다.
현재 브라우저 window 에서 이 URL 을 열거나 popup 으로 열 수 있다.
user 는 Google 에서 인증하고, app이 요청하는 permission 들을 grant 해주게 된다. Google 은 그리고 나서 user 를 app 으로 다시 redirect 시킨다. 이 때 access token 와 함께 redirect 시킨다. app 은 이 access token 을 확인(verify)하고, API 요청을 만들때 사용된다.
Goolge OAuth 2.0 server
Google API들에 access 하기 위해서 OAuth 2.0 을 사용하는 모든 application은 authorization credential들을 가져야만 한다. 이 authorization credential 은 Google 의 OAuth 2.0 server 가 application 을 판별할 수 있게 해준다.
이 credential id 는 다음 link 에서 만들 수 있다.
여기서 authorized JavaSCript origins 를 설정하게 된다. 이 설정된 origin 에서 보내는 request 만 accept 하는 것이다.
auth code flow 를 사용하자.
위의 글의 내용은 요즘 브라우저에서 3rd party cookie 를 없애려는 움직임이 있다. 그런 이유로 implicit grant flow 는 더이상 auth 를 하는 방법으로 적절치 않다는 이야기다.
댓글 없음:
댓글 쓰기