Today I Learned
매일 배운 것을 정리하며 기록합니다. 인증에 대해서 공부했습니다.
해당 게시글에서는 OAuth 2.0을 줄여서 OAuth으로 대체하겠습니다.
Authentication(인증)
- Authentication은 authentic(진본인)에 명사형 접미사(-tion)가 붙어 만들어진 단어
- 네트워크나 서버에 접속할 때, 본인 여부와 정규 이용자 여부를 확인하는 방법
OAuth
- "OAuth는 인터넷 사용자들이 비밀번호를 제공하지 않고 다른 웹사이트 상의 자신들의 정보에 대해 웹사이트나 애플리케이션의 접근 권한을 부여할 수 있는 공통적인 수단으로서 사용되는, 접근 위임을 위한 개방형 표준이다.
이 매커니즘은 여러 기업들에 의해 사용되는데, 이를테면 아마존, 구글, 페이스북, 마이크로소프트, 트위터가 있으며 사용자들이 타사 애플리케이션이나 웹사이트의 계정에 관한 정보를 공유할 수 있게 허용한다." - OAuth를 사용한 임의의 사이트가 정보가 유출이 되더라도 사용자는 정보를 공유한 사이트의 아이디와 비밀번호를 임의의 사이트에 제공하지 않았기 때문에 정보는 안전함.
Flow
- ex)
저의 서비스 (Client), 페이스북 (Authorization Server, Resource Server)
- Resourc Owner(제 서비스를 이용하는 유저이면서, 페이스북 유저)가 Client에게 말합니다
- "너의 서비스에서 페이스북의 내 이미지를 사용할래."
- Client는 Resource Owner에게 Authorizaiton Server로 리다이렉트하면서 말합니다.
- "Authorizaition Server에게 Client가 리소스에 접근할 수 있도록 권한을 부여하겠다고 말해줘."
- Authorizaiton Server는 Resource Owner에게 묻습니다.
- "어떤 Client(제 3의 서비스)가 액세스 권한 부여를 요청하는데 허용할거야? 거부할거야?"
- Resource Owner는 Authorization Server에게 대답합니다.
- "이미지에 대한 액세스 권한만 부여할게."
- Authorizaition Server는 Client에게 말합니다.
- "Resource Owner가 액세스 권한을 허용해서 너에게 Authorization code를 줄게.
이 코드를 가져오면 내가 Access token으로 교환해줄게.
그 토큰을 갖고 Resource Server로 가면 리소스를 받을 수 있을거야."
- Client가 Authorization Server에게 말합니다.
- "여기 너가 주었던 Authorization code야. 내가 맞는지 확인해보고 맞으면 Access token으로 교환해줘"
(이 때, Authorization code가 확인되면, Access token을 받습니다.)
- Client는 Access token을 가지고 Resource Server에게 말합니다.
- "여기 Access token이 있어. Resource Owner가 요청한 리소스를 줄래?"
(이 때, Access token이 확인되면, 리소스를 받습니다.)
GitHub 예시
1. GitHub에 제 서비스를 등록합니다.
- 서비스를 등록하고 나면 client ID, client secrets를 발급
- client ID는 client에서 Resource Server로 접근할 때 사용되고, client secrets은 Access token을 발급받을 때 사용
- client secrets 외부 유출 금지.
2. Access token을 받아오기 위해서 먼저 Authorization code를 받아야 합니다.
-
Authorization code 절차를 거치는 이유는 보안성 강화에 목적이 있습니다.
-
Client에서 client secrets를 공유하고 액세서 토큰을 가지고 오는 것은 탈취될 위험이 있음
-
Client에서는 Authorization code만 받아오고 Server에서 Access token 요청을 진행
-
다음 API를 활용하여 Authorizaiton code를 발급
해당 API를 통해 GET요청을 한다면 다음과 같은 화면으로 리다이렉트 됩니다.
여기서 액세스 권한을 허용해주면 Authorization code를 받게 됩니다.
Authorize 버튼을 누르면 처음 지정했던 callback URL로 리다이렉트 되는데, callback URL을 보면 쿼리스트링으로 code의 값이 생긴 것을 확인할 수 있습니다.
그 값이 Authorization code입니다.
3. Authorization code를 통해 Access token을 받습니다.
-
API를 참고하여 client_id, client_secrect, authorization code를 POST 요청으로 보내고 Acess token 발급.
-
보안상의 이유로 authorization code를 서버로 보내주고 서버에서 access token 요청을 하는 것이 적절
정리하자면,
-
Client -> Server : authorization code를 보냄.
-
Server -> Client : Client에게 받은 authorization code를 이용하여 API를 따라 Access token을 받아내고 Client에게 전달.
-
Access token을 이용해 resource에 접근.
Access token을 예시처럼 Authorizaiton header에 담아주어 GET 요청을 하면 원하는 리소스를 받아낼 수 있음.
이제 받아낸 리소스들을 원하는 대로 사용 가능.
느낀 점
처음 OAuth를 마주했을 때, 복잡한 과정에 겁을 먹었는데 우선 흐름을 이해하기 위해 종이에 몇 번 적어보니 이해가 되었습니다.
이해가 된 후에는 복잡한 과정도 굉장히 단순하게 느껴졌습니다.
코드를 바로 작성하기 보다 역시나 이해하는 시간과 손코딩의 시간을 갖는 것이 저에게 좋은 방법이라고 느꼈다.
결국 말로 설명할 수 있고, 종이에 간략하게 작성할 수 있어야 코드를 적을 수 있는 것임을 다시 한 번 깨달았습니다..
그리고 API 문서를 보는 능력이 많이 늘었다고 느껴졌습니다.
물론 API 문서가 짧고 잘 되어 있어서 이전에 비해 쉬웠지만, 그래도 몇 번의 경험 덕분인지 API 문서가 스트레서로 느껴지지 않고 오히려 도움을 주는 도구로 반갑게 느껴졌습니다.
쿠키, 세션, 토큰 그리고 OAuth까지 인증에 대해 전반적인 공부를 하였는데 흐름을 알고 나니 그동안 서비스에서 인증했던게 이런 방식으로 되었겠구나 알게 되어 흥미로웠습니다.
그리고 토큰에서 미리 고생한 덕분에 여기서 토큰을 사용할 때 비교적 수월했던 거 같습니다.
역시 기본은 시간이 걸리더라고 제대로 잡고 가는게 중요함을 느꼈습니다.
토큰에 대해 부족한 부분을 다시 채워넣고 OAuth도 복습을 해야겠습니다.
