OAuth 2.0의 Implicit Grant Type
Implicit Grant Type은 "token" 방식이라고도 하며, 클라이언트가 클라이언트 시크릿을 안전하게 저장할 수 없는 클라이언트 측 애플리케이션을 위해 주로 설계되었습니다. 이러한 애플리케이션에는 싱글 페이지 앱(SPA) 또는 기타 브라우저 기반 애플리케이션이 포함됩니다. 액세스 토큰으로 교환해야 하는 인가 코드를 받는 대신, 애플리케이션이 액세스 토큰을 직접 받습니다.
Implicit Grant Type은 어떻게 작동하나요?
- 리다이렉션:
- 클라이언트 애플리케이션이 사용자를 OAuth 2.0 인가 서버의 인가 엔드포인트로 리다이렉트합니다. 이 리다이렉션에는 일반적으로
client_id,response_type(Implicit Grant의 경우 "token"으로 설정),redirect_uri(접근 부여/거부 후 인가 서버가 리다이렉트할 위치),scope(요청된 접근 수준) 등의 쿼리 파라미터가 포함됩니다.
- 사용자 인증:
- 사용자가 인가 서버에 로그인하고(아직 로그인하지 않은 경우) 클라이언트 애플리케이션의 접근 요청을 검토합니다.
- 액세스 토큰 발급:
- 사용자가 접근을 부여하면, 인가 서버가 제공된
redirect_uri를 통해 사용자를 클라이언트 애플리케이션으로 다시 리다이렉트합니다. 리다이렉트 URI에는 URL의 프래그먼트 부분에 직접 액세스 토큰(및 만료 시간)이 포함됩니다.
- 보호된 리소스 접근:
- 클라이언트 애플리케이션이 URL 프래그먼트에서 액세스 토큰을 추출하여 저장합니다(예: 로컬 스토리지 또는 세션). 그런 다음 이 토큰을 사용하여 사용자를 대신하여 리소스 서버(API)에 요청을 보냅니다.
Implicit Grant Type을 구성하는 방법
- 애플리케이션 등록:
- OAuth 2.0 프로바이더에 애플리케이션을 등록하는 것부터 시작합니다. 등록 성공 후 일반적으로
client_id를 받습니다.
- Redirect URI 설정:
- 등록 시
redirect_uri를 제공합니다. 인가 서버는 사용자가 접근 부여 또는 거부를 결정한 후 이 URI로 사용자를 리다이렉트합니다. 이 URI가 안전하고(일반적으로 HTTPS 사용) URL 프래그먼트에서 토큰 추출을 처리할 수 있는지 확인하세요.
- OAuth 흐름 시작:
- 필요한 파라미터와 함께 사용자를 인가 서버의 인가 엔드포인트로 리다이렉트합니다. 애플리케이션의 언어나 프레임워크에 적합한 라이브러리 또는 SDK를 사용하여 이를 용이하게 합니다.
- 토큰 추출 및 저장:
- 다시 리다이렉트되면 URL 프래그먼트에서 액세스 토큰을 추출합니다. Web Storage(localStorage 또는 sessionStorage) 또는 쿠키와 같은 클라이언트 측 저장 옵션을 고려하여 토큰을 안전하게 저장합니다. 크로스 사이트 스크립팅(XSS) 공격으로부터 보호되도록 합니다.
- 토큰 사용:
- 리소스 서버에 보내는 API 요청에 액세스 토큰을 첨부합니다.
- 토큰 만료 처리:
- Implicit Grant는 일반적으로 리프레시 토큰을 제공하지 않으므로, 액세스 토큰이 만료되면 새 토큰을 얻기 위해 OAuth 흐름을 다시 시작해야 할 수 있습니다.
고려 사항:
보안: Implicit Grant Type은 Authorization Code Grant Type보다 덜 안전한 것으로 간주됩니다. 특히 액세스 토큰이 URL에 노출되기 때문입니다. 이는 URL이 기록되거나 제3자가 접근할 수 있는 환경에서 위험할 수 있습니다.
리프레시 토큰 없음: 일반적으로 Implicit Grant는 리프레시 토큰을 제공하지 않습니다. 따라서 액세스 토큰이 만료되면 전체 흐름을 반복해야 할 수 있습니다.
폐지 권고: 본질적인 보안 우려로 인해, OAuth 2.0 보안 모범 사례 문서에서는 SPA와 같은 공개 클라이언트에 대해 Implicit Grant 대신 PKCE(Proof Key for Code Exchange)를 포함한 Authorization Code를 사용할 것을 권장합니다.
결론:
Implicit Grant Type은 클라이언트 측 앱을 위한 더 간단한 흐름을 제공하지만, 보안 우려로 인해 현대 애플리케이션에서는 사용을 권장하지 않습니다. 특히 SPA와 같은 새 애플리케이션을 구축하는 경우, 보다 안전한 접근 방식으로 PKCE를 포함한 Authorization Code Grant를 사용하는 것을 고려하세요.