OAuth 2.0 자세히 살펴보기 #2 by IBM API Management

안녕하세요 이정운 입니다.

지난번에 공유해드린 OAuth 2.0 의 Authorization Code Grant Type 에 대한 정리의 많은 관심(?)에 감사드리며 부족한 지식이긴 하지만 제가 테스트해본 다른 grant type 에 대한 내용도 공유 드리도록 하겠습니다. 이번 강좌에서 공유드릴 내용은 Implicit Grant Type Flow 와 Client Credential Grant Type Flow 입니다.

#2) Implicit Grant Type Flow

Authorization Code Grant Type Flow 에 비해 Implicit Grant Type Flow 는 조금 더 단순한 형태로 되어 있으며 그림에 표시된 순서대로 이야기 드리자면 하단과 같습니다.

1. Resource Owner 가 client 를 통해서 인가(Authorization) 을 시작

2. client 가 Resource owner 를 바로 Authorization server 로 리다이렉트
   - Resource owner 는 username/password 로 인증 요청
   - Authorization server 가 Access token 을 즉시 생성한 후 client 에게 redirection URL 을 통해서 전달

3. Client 는 resource 요청을 하면서 Resource Server 에 Access token 을 전달
   - Resource server 는 Access token 을 검증하고 요청된 resource 를 client 에게 전달

Implicit Grant Type Flow 는 Implicit 라는 말뜻 그대로 암시적으로(?) 자원에 접근할 수 있도록 해줍니다. 이를 좀 더 이해하기 쉽게 설명드리면 이전에 Authorization Code Grant Type 은 중간에 인증을 거쳐서 Authorization code 를 받아와야만 이를 통해 Access token 을 얻을 수 있었습니다. Implicit Grant Type Flow 는 이 단계를 줄여서 암시적으로 인가되었다고 가정하고 바로 Access token 을 받아올 수 있으며 이를 통해서 API call 을 진행하는 방식입니다. 기존 강의에서 언급한 것처럼 본 강의도 IBM API Management 를 이용해서 테스트를 수행할 것입니다. 다시 한번 강조드리지만 IBM API Management 가 없더래도 OAuth 의 흐름만 보고 이해에 도움을 얻으면 그걸로 충분할 것으로 판단됩니다.

그럼 우선 들어가기 전에 해당 설정을 간단히 살펴보도록 하겠습니다.

지 금 설정에 대해서 간단히 설명드리면 Client Type 으로 Public 을 사용한다는 것이며 이는 인증을 수행할 때 Client Id 와 Client Secret 을 둘 다 체크하지 않고  Client Id 만 본다는 의미이며 Grant Type 으로 Implicit 를 사용하겠다는 설정입니다. 또한, 인가 전에 인증이 필요한데 이는 위에 적은 URL 로 처리한다는 것입니다.(실제 해당 URL 은 빈 페이지를 리턴하는 URL 로 테스트 목적으로 별도의 Authentication 을 하지 않는다는 의미입니다.)

그럼 이제 해당 테스트에 대한 준비는 완료되었고 실제적으로 OAuth 2.0 테스트를 수행해보도록 하겠습니다.

curl -k "http://192.168.225.52:9000/apim2/loans7/v1/oauth/authorize?response_type=token&client_id=62739a0a-7efd-46fd-aeda-e1f0fe3e2fb1&redirect_uri=https://localhost&scope=/loans7/v1" --user test:test -v -o test.html

위 의 작업을 간단히 설명드리면 OAuth 를 위한 authorize 페이지에 response_type 은 token 으로(바로 token 을 받아오겠다는 의미) 식별을 위한 client_id 와 token 을 전달받을 redirect_uri, 범위(scope) 를 요청으로 보내는 것입니다.(기 언급한 것처럼 Authentication 은 테스트이기 때문에 아무값이나 넣어도 됩니다. 마지막으로 그 진행 결과를 화면에 보여주고 마지막 응답 결과는 test.html 이라는 파일로 만드는 작업을 수행합니다.

이렇게 만들어진 test.html 을 더블 클릭하면 Authorization Code Grant Type 에서와 동일하게 하단과 같이 consent page 를 브라우저에서 확인하실 수 있습니다.

해 당 consent page 에서 Allow 버튼을 클릭하면 지난번과 동일하게 오류가 난것을 확인할 수 있는데 보다 중요한 것은 Authorization Code Grant Type 과  다르게 Authorization code 대신에 Access Token 을 바로 반환받을 수 있습니다.

이렇게 Access Token 을 받았으면 Authorization Code Grant Type Flow 와 동일하게 해당 Token 으로 바로 원하시는 API 를 호출할 수 있습니다.

curl -k -v --Header "Authorization: Bearer AAEFcC1hbGxCgPaGA-r9QKXumoNOLYKuRADPZH7Fx7pSJ0dTIHyJsi6kAzNIi98f9VN4QgjkJDrpPiFiTjjIYbuzZmZVkcFoee0huebFNTs_jDB0W12n5aakDDZDaShnbcpAQv4HGcp35Y7vw60-qjHLCJwd146J" "http://192.168.225.52:9000/apim2/loans7/v1/quote?loanAmount=20000&annualInterestRate=0.9&termInMonths=52&client_id=0423a0a5-9ff5-42e5-8d82-ffcbd5df97c3"\

이렇게 하시면 정상적으로 결과가 나오는 것을 확인할 수 있습니다. 직접 테스트를 수행해봐서 아시겠지만 Implicit Grant Type Flow 는 Authorization Code Grant Type Flow 에 비해 단계를 줄이고 보다 효율적으로 인증/인가 작업을 수행할 수 있습니다.
(다만, 당연히 단계가 줄었다는 것은 그만큼 체크를 덜 한다는 의미이고 보안적으로만 따졌을 때는 좀 더 느슨하다고 이해하시면  됩니다.)


#3) Client Credentials Grant Type Flow

기 존에 테스트했던 Grant Type Flow 들에 비해Client Credentials Grant Type Flow 는 더 단순한 형태로 되어 있으며 상단의 그림과 같이 2 legged 방식으로 수행하도록 되어 있습니다. 이를 좀 더 자세히 그림에 표시된 순서대로 이야기 드리자면 하단과 같습니다.

1. client 가 Ahthorization Server 에 직접 인가 및 보호된 Resource 에 대한 접근 요청
   - Authorization server 는 client credentials 을 검증 하고 Access Token 을 반환

2. Client 는 resource 요청을 하면서 Resource Server 에 Access token 을 전달
   - Resource server 는 Access token 을 검증하고 요청된 resource 를 client 에게 전달

설 명을 보시면 아시겠지만 Client Credentials Grant Type Flow 는 보다 단순하게 인증을 수행하고 바로 자원에 접근할 수 있도록 해줍니다. 그럼 이제 테스트 해보면서 실제로 이해해보는 시간을 가져보도록 하겠습니다.

우선 해당 테스트를 수행하기 위한 기본 설정은 하단과 같습니다.  

상단의 설정에 대해서 간단히 설명드리자면 Client Type 은 Confidential 로 하였으며(Client id 와 Client secret 을 다 본다는 의미입니다.) Grant Type 은 Client Credentials 로 설정하였습니다. 이전에 보여드렸던 Authorization Code Grant Type 설정과는 다르게 Authentication 부분은 사용하지 않으므로 자동으로 비활성화 됩니다. (참고로 Refresh token 은 사용하지 않는 형태로 설정했는데 원하시면 enable 할 수도 있습니다.)

그럼 이제 준비는 완료되었고 실제적으로 OAuth 2.0 테스트를 수행해보도록 하겠습니다. cURL 을 이용해서 하단의 REST 명령을 수행합니다.

curl -v -k -H "Content-Type:application/x-wwww-form-urlencoded" -u "0423a0a5-9ff5-42e5-8d82-ffcbd5df97c3:A6xH1dM6wW5vM7eN8rI6uB7eO5oT1pD6eM1cD2bF3rI1mK7qS4" --data-binary "grant_type=client_credentials&scope=/loans2/v1" "http://192.168.225.52:9000/apim2/loans2/v1/oauth/token"

위 의 작업을 간단히 설명드리면 기 지정된 OAuth 의 token 을 위한 페이지에 grant_tpye 은 client_credentials 로 실제 전달될 client credential 은 client id 와 client secret 을(상단의 -u 다음 항목) 범위(scope) 와 함게 요청으로 보내는 것입니다. 이렇게 요청을 보내면 Authorization server 는 client credential 을 검증하고 정상이면 바로 Access token 을 반환합니다. 결국 Implicit Grant Type Flow 와 유사하게 client credential 검증만으로 인가되었다고 판단하고 Access Token 을 반환하는 것입니다. 실제로 해당 명령을 수행하면 하단과 같은 결과를 얻을 수 있습니다.

이렇게 Access token 을 가지고 왔으면 나머지 작업은 다른 Grant Type 과 동일합니다. 응답으로 받은 Access token  을 이용하여 실제 API 를 호출하게 되면 결과를 확인할 수 있습니다.

curl -k -v --Header "Authorization: Bearer AAEFYy1hbGwhI-1nf9OS3HNLzm0jz4lhCy_QKOCpV6WC3_Q-y9a7VZMu3GGQGtewj3gz83BjOTSL0QIpmvWadA-NqXM5uV4Qx23jsO-01dFi4SBZA7nGmc15EXGWZOqpPz8ghYGJeqZHIqRP0RlYaizr8ZJiTzee" "http://192.168.225.52:9000/apim2/loans2/v1/quote?loanAmount=20000&annualInterestRate=0.9&termInMonths=52&client_id=0423a0a5-9ff5-42e5-8d82-ffcbd5df97c3"

여기까지 잘 따라오셨다면 OAuth 2.0 의 Client Credentials Grant Type 테스트를 잘 완료하신 것입니다. 기 언급한 것처럼 이번 강좌에서 다루었던 2가지 grant type 은 이전 강좌에서 언급한  Authorization Code Grant Type 보다 훨씬 간결한 flow 를 가지고 있으며 상황에 따라서 좀 더 효율적으로 인증/인가 작업을 수행 가능합니다.

그럼 이번 강좌는 여기서 마치도록 하겠습니다....^^&