AZ-204 Certified: 4-Day Authentication and Authorization in App Service

관련 글 정보

인증 및 권한 부여

Azure App Service는 웹 애플리케이션, API 서비스, 그리고 모바일 앱의 백엔드를 운영할 수 있게 해주는 클라우드 서비스입니다.

이 서비스를 사용하면 개발자는 사용자 로그인 기능이나 데이터 접근 권한을 확인하는 기능을 직접 만들 필요 없이, Azure가 제공하는 기능을 쉽게 추가할 수 있습니다. 또한, Azure Functions와 함께 사용하면 서버 쪽 로직을 특정 이벤트에 맞춰 자동으로 실행할 수 있는 코드를 만들 수 있습니다.

한 줄 요약: 복잡한 인증 코드를 직접 작성하지 않고도 안전하게 사용자 관리를 할 수 있게 해줍니다.

Feature architecture

기본 제공(Built-in) 인증을 사용하는 이유

인증 및 권한 부여 기능은 개발자가 추가적인 보안 코드를 작성하지 않고도 로그인과 데이터 접근 제어를 할 수 있도록 도와줍니다. 많은 웹 프레임워크가 자체적인 보안 기능을 가지고 있지만, Azure의 기능을 사용하면 이러한 기능을 더 쉽게 구현할 수 있습니다.

개발자가 더 많은 컨트롤(제어)을 원한다면 자신만의 인증 시스템을 작성할 수 있지만, Azure App Service는 다양한 외부 로그인 서비스(예: Microsoft Entra ID, Facebook, Google, Twitter)와 쉽게 통합되므로, 개발자는 애플리케이션의 다른 중요한 부분에 더 집중할 수 있습니다.

Azure Functions와 결합하면 이 인증 기능을 서버리스 환경에서도 활용할 수 있습니다.

작동 방식

App Service 인증 및 권한 부여 모듈은 애플리케이션의 나머지 부분과 같은 환경에서 작동합니다. 이 모듈이 활성화되면, 애플리케이션으로 들어오는 모든 HTTP 요청은 먼저 이 모듈을 거쳐서 사용자가 누구인지 확인하고, 그들이 애플리케이션의 특정 부분에 접근할 수 있는 권한이 있는지 검사합니다.

주요 기능은 다음과 같습니다

  • 특정 ID 제공자를 통해 사용자와 클라이언트를 확인합니다.
  • ID 제공자로부터 받은 OAuth 토큰이 유효한지 검사하고, 이를 저장하며 필요할 때 새로 고칩니다.
  • 로그인된 사용자의 세션을 관리합니다.
  • HTTP 요청 헤더에 사용자의 ID 정보를 추가합니다.

이 모듈은 Azure Resource Manager 설정이나 애플리케이션의 구성 파일을 통해 설정할 수 있으며, 개발자는 이를 위해 별도의 SDK를 사용하거나 특정 프로그래밍 언어를 배울 필요가 없습니다. 개발자는 애플리케이션 코드를 수정하지 않고도 이 기능을 사용할 수 있습니다.

Linux 참고 사항

Azure App Service에서 Linux 및 컨테이너를 사용하는 경우 인증 및 권한 부여 모듈은 애플리케이션 코드가 실행되는 것과는 별개의 컨테이너에서 작동합니다. 이 설정은 모듈이 애플리케이션과 같은 프로세스 내에서 실행되지 않음을 의미합니다.

그 결과, 이 모듈은 특정 언어나 프레임워크와 직접적으로 통합되지 않습니다. 그러나 이 구조는 모듈이 언어와 프레임워크에 독립적이라는 이점을 제공하여, 다양한 애플리케이션 환경에 유연하게 적용될 수 있도록 합니다. 개발자는 이 모듈을 활용해 인증과 권한 부여를 관리하면서, 애플리케이션 코드에 집중할 수 있습니다.

인증(Authentication) 프로세스

Azure App Service 인증에는 두 가지 주요 흐름(Flow)이 있습니다.

  1. 공급자1 SDK가 없는 경우:
    • 여기서, 애플리케이션은 사용자 인증을 Azure App Service에 맡깁니다.
    • 사용자는 웹 기반의 로그인 페이지로 리디렉션되어 그곳에서 인증합니다.
    • 이 프로세스는 서버 측에서 완전히 처리되며, 이를 ‘서버 흐름(Flow)’이라고 부릅니다.
  2. 공급자 SDK 사용:
    • 애플리케이션은 직접 사용자를 공급자에 로그인시키고, 이후 Azure App Service에 토큰을 전달합니다.
    • 이 경우, 로그인 페이지가 제공되지 않는 상황에서 사용되며, 클라이언트 측에서 로그인이 처리됩니다.
    • 애플리케이션 코드가 인증 과정을 직접 다루기 때문에, 이를 ‘클라이언트 흐름’이라고 합니다.

이 두 흐름은 다른 종류의 애플리케이션(예를 들어, 브라우저가 있는 앱과 브라우저가 없는 앱)에서 인증 방식을 구현할 때 선택할 수 있으며, 애플리케이션의 요구와 환경에 맞게 선택할 수 있습니다.

권한 부여(Authorization) 프로세스

Azure Portal에서 App Service 인증을 설정할 때, 인증되지 않은 요청을 어떻게 처리할지 결정해야 합니다. 다음과 같은 두 가지 주요 옵션이 있습니다:

  1. 인증되지 않은 요청 허용 (Allow unauthenticated requests):
    • 이 옵션은 애플리케이션에서 인증을 요구하지 않고 모든 요청을 받아들입니다.
    • 애플리케이션은 인증된 사용자와 인증되지 않은 사용자의 요청을 모두 받을 수 있으며, 코드 내에서 이를 구분하여 처리할 수 있습니다.
    • 인증된 요청의 경우, App Service는 인증 정보를 HTTP 헤더에 포함시켜 애플리케이션에 전달합니다.
  2. 인증 필요 (Require authentication):
    • 이 옵션을 선택하면 모든 요청은 인증을 거쳐야 합니다.
    • 인증되지 않은 요청은 자동으로 로그인 페이지로 리디렉션되거나, 401(Unauthorized) 또는 403(Forbidden) 오류를 반환받게 됩니다.
    • 구체적으로, 웹 앱에서는 사용자를 로그인 페이지로 리디렉션할 수 있고, 네이티브 모바일 앱에서는 보통 401 오류를 반환합니다.

만약 애플리케이션에 공개적으로 접근 가능한 홈페이지와 같은 일부 공개 컨텐츠가 있다면, 모든 요청에 대해 인증을 요구하는 설정은 적합하지 않을 수 있습니다. 이런 경우에는 ‘인증되지 않은 요청 허용’을 선택하고, 애플리케이션 로직을 사용하여 인증이 필요한 부분만 인증을 요구하도록 설정하는 것이 좋습니다.

토큰 저장소(Token store)

App Service는 웹앱, API 또는 기본 모바일 앱의 사용자와 연결된 토큰(Token)2 리포지토리인 내장 토큰 저장소를 제공합니다. 공급자와 인증을 사용하도록 설정하면 이 토큰 저장소를 앱에서 즉시 사용할 수 있습니다.

https://www.okta.com

로깅 및 추적

애플리케이션 로깅을 사용하도록 설정하면 로그 파일에 인증 및 권한 추적이 바로 수집됩니다. 예상치 못한 인증 오류가 표시되면 기존 애플리케이션 로그를 보고 모든 세부 정보를 편리하게 찾을 수 있습니다.

Learning Note

  1. 공급자(Provider)
    Azure App Service에서 말하는 ‘공급자’는 사용자가 인증할 때 신원을 확인하는 서비스를 말합니다. 쉽게 말해, 사용자가 애플리케이션에 로그인할 때 사용하는 계정을 제공하는 회사나 서비스입니다.

    예를 들어, Google, Facebook, Microsoft 계정과 같은 것들이 ‘공급자’가 될 수 있습니다. 사용자는 이런 서비스의 계정으로 다른 애플리케이션에 로그인할 수 있기 때문에, 각각의 애플리케이션에 별도로 계정을 만들 필요가 없어 편리합니다.

    Azure App Service는 이러한 공급자들과의 연동을 쉽게 설정할 수 있게 도와줍니다.
    ↩︎
  2. 토큰(Token)
    토큰은 인터넷에서 사용자의 신원을 확인하고 권한을 부여하기 위한 일종의 전자 열쇠와 같습니다. 사용자가 온라인 서비스에 로그인할 때, 그 서비스는 사용자가 누구인지 확인하고, 사용자가 요청하는 작업을 할 수 있는 권한이 있는지 확인해야 합니다. 이때, 서비스는 사용자에게 토큰이라는 코드를 줍니다.

    이 토큰은 안전하게 사용자의 신원 정보와 권한을 담고 있으며, 사용자가 다른 작업을 요청할 때마다 이 토큰을 서비스에 보내서 자신이 누구인지 그리고 해당 작업을 할 권한이 있는지를 증명합니다. 서비스는 이 토큰을 확인하고, 토큰이 유효하다면 사용자가 요청한 작업을 수행할 수 있게 해줍니다.

    예를 들어, 사용자가 이메일 서비스에 로그인하면, 서비스는 사용자의 이메일과 비밀번호를 확인한 뒤, 토큰을 줍니다. 그 후 사용자가 이메일을 확인하거나 새로운 이메일을 작성할 때마다 이 토큰을 이용해서 자동으로 사용자를 인증합니다. 이로 인해 사용자는 매번 이메일과 비밀번호를 입력할 필요 없이, 서비스를 원활하게 이용할 수 있습니다.
    ↩︎