MCP용 Zero-Touch OAuth

 (blog.modelcontextprotocol.io)
1P by GN⁺ | ★ favorite | 댓글 1개
  • Enterprise-Managed Authorization(EMA) 확장이 안정화되어, 기업은 MCP 서버 권한을 중앙에서 관리하고 사용자는 한 번 로그인해 허가된 서버에 접근할 수 있게 됨
  • 기존 방식은 사용자별·서버별 개별 OAuth 승인에 의존해 온보딩, 보안 정책 적용, 감사 추적, 업무·개인 계정 분리를 어렵게 만듦
  • EMA는 조직의 IdP를 권한 결정 주체로 두고, 관리자가 정책을 한 번 정의하면 사용자는 기존 조직 계정으로 필요한 MCP 연결을 상속받음
  • SSO 중 발급된 ID-JAG를 MCP 서버의 인가 서버에서 액세스 토큰으로 교환하므로, 사용자는 서버별 동의 화면으로 리다이렉트되지 않음
  • Okta, Anthropic, Visual Studio Code와 Asana·Atlassian·Canva·Figma·Granola·Linear·Supabase가 초기 지원에 포함됐고, Slack도 지원을 추가 중임

EMA 안정화와 기업 배포 목표

  • Enterprise-Managed Authorization(EMA) extension이 stable 상태가 됨
  • 기업 환경에서 MCP 서버 연결을 관리할 때 반복 승인과 동의 프롬프트가 큰 불편으로 꼽혔고, EMA는 이 문제를 줄이기 위한 확장임
  • 조직은 신뢰하는 ID 공급자(IdP) 를 통해 MCP 서버 접근을 중앙에서 제어할 수 있음
  • 최종 사용자는 기존 조직 계정으로 로그인한 뒤 허가된 MCP 서버에 연결되며, 서버별 OAuth 동의나 일회성 설정 부담이 줄어듦

사용자별 인증 모델의 한계

  • 표준 MCP 권한 모델은 사용자 범위(user-scoped) 와 전통적인 대화형 인증 관례에 맞춰 설계됨
  • 개인이 자신의 데이터 접근 대상을 직접 결정하는 소비자 시나리오에는 맞을 수 있지만, 기업 배포에서는 잘 확장되지 않음
  • 기업 환경에서는 특히 세 가지 문제가 커짐
    • 직원마다 서버를 각각 승인해야 하므로 온보딩 때 서비스별 수동 연결이 필요함
    • 보안팀은 중앙 제어나 감사 추적 없이 각 사용자가 승인한 접근에 의존하게 됨
    • 회사 계정을 강제하기 어려워 사용자가 개인 계정을 업무 도구에 연결할 수 있음
  • 이런 마찰은 MCP 도입을 늦추고, 취약한 우회 구현을 만들 가능성을 높임
  • 공유 인증 상태를 보존하는 범용 표준이 없으면 구현자마다 별도 해결책을 만들게 되고, 데이터와 도구가 있어도 사용자별 권한 비용 때문에 대부분 꺼진 상태로 남을 수 있음

한 번 승인하고 어디서나 상속

  • Enterprise-Managed Authorization은 조직의 IdP를 MCP 서버 접근의 권한 결정 주체로 만듦
  • 관리자는 정책을 한 번 정의하고, 사용자는 기존 조직 ID로 MCP 호스트에 인증함
  • IdP는 그룹 멤버십, 역할, 조건부 접근 규칙에 따라 접근을 허용하거나 거부할 수 있음
  • 내부 흐름은 다음과 같음
    • 클라이언트가 SSO 중 IdP에서 Identity Assertion JWT Authorization Grant(ID-JAG)를 얻음
    • 클라이언트가 이를 MCP 서버의 인가 서버에 보내 액세스 토큰으로 교환함
    • 사용자는 서버별 동의 화면을 거치지 않음
  • 이 구조가 주는 효과는 세 가지임
    • 관리자가 조직에 서버를 활성화하면 사용자는 기존 그룹과 역할 범위 안에서 자동으로 접근함
    • 접근 결정은 IdP 관리자 콘솔에 남아, 모든 커넥터에 대해 하나의 감사 가능한 기록을 제공함
    • 대화형 계정 선택 단계를 제거해 개인 계정과 기업 계정 사이의 데이터 흐름 혼선을 줄이기 쉬워짐
  • MCP 기업 사용에서 목표는 사용자가 로그인했을 때 추가 단계 없이 허가된 도구와 데이터에 클라이언트가 연결되는 상태임

초기 지원 제품과 생태계

  • 이번 출시에는 ID 공급자, 클라이언트, 서버 세 그룹이 구현에 참여함

  • ID 공급자

    • Okta가 첫 번째 지원 ID 공급자임
    • Okta 사용 조직은 Okta’s Cross App Access(XAA)를 통해 지원 클라이언트와 서버에 MCP 접근을 프로비저닝할 수 있음

  • 클라이언트

    • Anthropic은 Claude의 공유 MCP 계층에 EMA를 구현함
    • 관리자는 Claude, Claude Code, Cowork 전반에서 사용자용 MCP 서버를 승인할 수 있음
    • Visual Studio Code도 IDE 안에 EMA 지원을 추가함

  • 서버

    • Asana, Atlassian, Canva, Figma, Granola, Linear, Supabase가 EMA를 지원함
    • Slack과 그 외 서버들도 지원을 추가 중임
    • Okta의 Aaron Parecki는 Cross App Access 프로토콜을 MCP의 EMA 확장에 내장해 identity를 중앙 거버넌스 평면으로 만들고, 보안팀에는 컴플라이언스 제어를, 사용자에게는 매끄러운 경험을 제공한다고 말함
    • Figma의 Devdatta Akhawe는 MCP 도입이 늘면서 XAA가 기업의 MCP 배포를 보안적으로 확장하기 쉽게 만든다고 말함
    • Linear의 Tom Moor는 한 번 로그인하면 모든 MCP 커넥터가 자동 설정되는 경험을 언급함

문서와 참여 채널

  • 클라이언트, 서버, identity platform은 확장 명세를 검토하고 제품에 새 표준 지원을 추가할 수 있음
  • Enterprise-Managed Authorization page는 클라이언트, 서버, 인가 서버를 위한 흐름 요구사항을 문서화함
  • ext-auth repository와 draft specification에서 EMA의 최신 변경과 지원 자료를 확인할 수 있음
  • 확장 논의, 호환성 보고, 반복 개선에는 EMA Interest Group이 사용됨
  • EMA는 MCP 커뮤니티 작업으로, SEP-990 작성자, ext-auth 저장소 유지관리자, 초기 구현을 테스트하고 명세를 진전시킨 identity 및 MCP provider가 기여함

함께 보면 좋은 글 β

GN⁺   [-]
Hacker News 의견들

  • 흔한 “MCP는 죽었고 Skills가 미래” 논쟁으로 가기 전에, MCP가 skills/CLI보다 실제로 가치 있는 지점은 인증 흐름을 에이전트의 컨텍스트 창 밖으로, 경우에 따라 하니스 밖으로까지 분리한다는 데 있음
    보안 관점에서도 당연히 중요하고, 일반 사용자나 대기업이 AI 도구를 도입할 때 훨씬 쉬운 사용자 경험이 됨
    컨텍스트 비대화나 도구 호출 중복에 대한 불만은 이해하지만, 인증을 이렇게 다루는 구조에는 분명한 가치가 있음
    이상적인 MCP는 API 앞단의 인증 게이트웨이만 해도 충분히 이득일 수 있음

    • 이 확장은 skills 대비 MCP의 다른 장점도 잘 보여줌: 중앙 통제, 직원 입장에서의 사용 편의성, 감사/컴플라이언스, 배포 모델
      지금 skills 배포의 최선은 “이 파일을 복사해서 여기에 넣기”, “이 저장소를 체크아웃하고 심볼릭 링크 추가”, “슬래시 명령으로 설치” 정도로 보임
      단순하긴 해도, 새 MCP 서버를 직원에게 배포하는 이 확장 방식만큼 쉽지는 않음
    • MCP는 훌륭한 감사 추적도 가능하게 해줌
      예를 들어 6개 고객사의 Linear 계정 6개를 인증해두고, 어떤 계정을 쓸지 결정론적이고 감사 가능한 방식으로 선택하는 식의 책임 분리도 가능함
    • MCP 대 skills는 이분법이 아니라는 게 진짜 교훈임
      둘은 그냥 서로 다른 도구이고, 요구사항에 따라 어느 쪽이 더 나을 수도 있고 아닐 수도 있음
      칼과 톱 중 뭐가 더 낫냐는 질문과 비슷함
    • 그 외에도 MCP는 런타임 환경 없이 외부 플랫폼을 연결할 수 있게 해줌
      이 주제가 나올 때마다 엔지니어들은 Claude Code만 AI 에이전트의 유일한 앱인 것처럼 다루지만, 코딩 외 여러 업종에도 수많은 사용 사례가 있음
      하니스가 로컬 머신이 아니라 클라우드의 격리되고 제한된 컨테이너에서 돌고, 임의 코드 실행은 절대 안 되는 환경일 수 있음
      그래도 고객이 기존 도구를 에이전트에 연결하길 원할 때 MCP는 내장 인증이 있는 커넥터를 제공하므로 딱 맞고, skills는 이 영역에 해당하지 않음
    • 친구들과 식당 리뷰를 하는 플랫폼을 만들고 있는데, 몇 번 시행착오 끝에 MCP가 맞는 방향으로 보임
      일반 사용자는 Claude 디렉터리를 찾아 skill 파일을 붙여넣지 않음
      “Connections”는 이해하기 쉽고, MCP를 붙여넣거나 마켓플레이스에서 찾는 편이 더 쉬움
      장소와 리뷰에 에이전트가 접근하는 게 실제로 유용할지는 아직 미정임

  • Okta, Anthropic, Microsoft, Figma, Linear 등에서 이 작업을 만든 사람들에게 큰 축하를 보냄
    MCP 회의론자들에게도 쓸 만한 게 있음
    이건 ID-JAG라는 새 토큰 형식으로 동작하며, https://datatracker.ietf.org/doc/draft-ietf-oauth-identity-a...에 있음
    MCP 전용이 전혀 아니고, 같은 SSO 제공자를 쓰는 애플리케이션 사이에서 데이터를 안전하게 공유해야 하는 곳이라면 어디든 ID-JAG를 쓸 수 있음

    • 이런 회사들 때문에 소프트웨어와 삶의 질이 더 나빠졌으니, 정말 축하할 일이라는 냉소가 듦

  • 지금 구현 중인 MCP 서버에 Microsoft Entra ID 인증을 붙이려는데, 솔직히 내가 바보가 된 느낌임
    WWW-Authenticate 헤더로 클라이언트에 리소스 메타데이터 URL을 알려줄 수 있고, 이를 통해 인증 서버인 Microsoft Entra와 앱 등록 범위도 지정할 수 있음
    그런데 client_id는 지정할 수 없고, 그건 각 클라이언트, 즉 에이전트가 알아서 만든다는 식임
    Microsoft Entra의 .../authorize URL로 로그인을 시작하려면 Entra의 앱 등록과 일치하는 알려진 client_id가 필요한데, 클라이언트가 임의로 만든 값이 Entra에 맞을 리 없음
    이론상 동적 클라이언트 등록을 지원할 수는 있지만 Microsoft Entra는 당연히 지원하지 않음
    결국 Microsoft Entra 앞에 자체 동적 클라이언트 등록 shim을 만들어 모두에게 같은 정적 client_id를 돌려주는 방법밖에 안 보임
    이 프로토콜이 실제 엔터프라이즈에서 우회 없이 동작하는 게 맞는지, 내가 뻔한 걸 놓친 것 같은 느낌임

    • 뻔한 걸 놓친 건 아닌 듯함
      Entra ID는 동적 클라이언트 등록을 지원하지 않고, 이 생태계 상태는 아직 좋지 않음
      보통 MCP OAuth는 사전에 등록된 전통적인 클라이언트로 처리하지만, 실제로 많은 MCP 클라이언트는 동적 클라이언트 등록이 된다고 가정하고 client_id를 지정하는 옵션을 제공하지 않음
      다만 일부 클라이언트는 이를 지원하고, 광고를 겸하자면 우리 도구 Erato도 지원함: https://erato.chat/docs
      엔터프라이즈에서 배포되는 일반적인 솔루션도 보통 웹 UI를 통해 MCP 접근을 중앙화하므로 이를 지원함
      다른 대안으로는 MCP 게이트웨이가 있고, 게이트웨이와 서비스 사이에는 사전 등록 OAuth를 쓰고 게이트웨이와 클라이언트 사이에는 동적 클라이언트 등록을 허용할 수 있음
    • 우리도 client_id 때문에 같은 문제를 겪었고, 보안상 동적 클라이언트 등록을 켜고 싶지 않았음
      결국 앱이 OAuth 흐름을 프록시하면서 하드코딩된 client_id를 주입하게 만들었음
      MCP 클라이언트에게는 동적 클라이언트 등록을 지원한다고 속이지만, 내부에서는 MCP용 독립 client_id를 평소처럼 쓰는 구조임
      예시는 여기 있음: https://gist.github.com/erebe/a5de36d42214721b2466fb0e66f61c...
    • 바로 어제 구현했는데, 요지는 이 라이브러리가 MCP 서버를 실행한다는 것임: https://csharp.sdk.modelcontextprotocol.io/concepts/identity...
      그다음 OpenID로 클라이언트 등록을 처리하고 JWT를 만드는 인증 브로커 애플리케이션을 만들었음
      결과적으로 직원의 부서나 다른 기준으로 도구 사용 가능 여부와 권한을 결정할 수 있게 됨
      결국 동적 클라이언트 등록은 필요함
    • 최근 FusionAuth에서 사전 등록 클라이언트를 쓰는 방법을 문서화했음: https://fusionauth.io/docs/extend/examples/controlling-acces...
      DCR의 더 새롭고 나은 형제인 CIMD도 검토 중이고 활발히 논의 중이지만, 아직 제공되지는 않음: https://github.com/FusionAuth/fusionauth-issues/issues/3230
      제안한 프록시의 대안으로는 개발자 포털 등에서 MCP 클라이언트마다 PKCE가 켜진 새 Entra client_id를 만들고, 사용자가 그 값을 클라이언트에 설정하게 하는 방식이 있음
      이를 위한 CLI 명령은 여기서 찾았고 API도 있을 것 같음: https://learn.microsoft.com/en-us/cli/azure/ad/app?view=azur...
      Claude Code 설정은 https://code.claude.com/docs/en/mcp, ChatGPT 설정은 https://developers.openai.com/api/docs/guides/developer-mode에 있음
      사전 클라이언트 등록은 개발자에게는 최적은 아니어도 받아들일 수 있고, 명세에서도 1급 방식으로 다뤄짐: https://modelcontextprotocol.io/specification/2025-11-25/bas...
      주 사용자가 내부 직원이고 MCP 서버 접근을 위해 설정 지침을 따를 수 있다면 이 방식도 동작함
      하지만 대상이 개발자가 아닌 광범위한 공개 통합이라면 확실히 받아들일 만하지 않고, 바로 그 지점에 MCP의 큰 힘과 기회가 있음

  • Anthropic에서 Okta와 여러 MCP 파트너와 함께 이걸 만든 사람 중 하나임
    Claude에서 이 형태가 잡혀가는 게 매우 기대되고, MCP 명세에서도 EMA가 안정 확장이 된 만큼 다른 ID 제공자와 클라이언트로도 채택을 넓히고 싶음
    피드백이 있으면 여기 남겨주면 좋겠고, 실제 사용 경험과 개선할 방법을 언제나 듣고 싶음

    • 오랜만임
      한동안 MCP를 안 봤는데, 이건 조직에서 MCP를 더 안전하게 만들고 동적 클라이언트 등록의 약점을 해결하는 데 꽤 잘 맞는 듯함
      이제 클라이언트와 승인된 리디렉션 URI를 ID 제공자와 조직이 직접 설정할 수 있으니, 혼동된 대리자 공격이나 피싱 같은 DCR 기반 공격을 더 넓게 완화할 수 있음
      또 ID 제공자나 조직이 DCR을 지원하지 않던 경우 MCP 서버가 구현해야 했던 인가 로직도 줄어들어 큰 장점이 됨
      단점은 소비자 사용에는 여전히 DCR이 필요한 것처럼 보인다는 점임
      GitHub, GitLab, Google 같은 소비자 OAuth 제공자가 정적 MCP 클라이언트/서버 등록을 지원하고, 클라이언트가 정적 client_id를 내장하고, 사용자가 해당 ID 제공자로 로그인해 연결을 직접 관리하게 하면 해결 가능할 수도 있음
      전반적으로 XAA/EMA는 보안과 사용성 측면에서 DCR보다 훨씬 우월해 보임
      우려되는 부분도 DCR보다 훨씬 해결하기 쉽고 보안 영향이 작음. 공격자가 자기 클라이언트를 등록할 수 없고 MCP 서버 개발자가 빠질 함정도 줄어들기 때문임
    • 일반적인 “앱”에는 훌륭하지만, 우리에게는 사용자가 MCP를 설정하지 않고도 더 낮은 마찰로 에이전트 방식으로 상호작용할 방법이 절실함
      일종의 임시 세션이나 대역 외 토큰 저장소가 있으면 좋겠음
      사용 사례는 영업 과정에서 구매자와 판매자가 많은 정보를 교환하고 분석해야 하는데, 이 분석이 점점 에이전트식이 되고 있다는 것임
      MCP의 문제는 초기 설정 마찰이 사용자가 직접 로그인해서 필요한 정보를 가져오는 것보다 훨씬 크다는 점임
      MCP는 규칙적이고 빈번한 상호작용에는 좋지만, 빠른 일회성 세션에는 문제가 많음
      Claude에서 “X, Y, Z에서 문서를 가져와”라고 하면 Claude가 해당 웹사이트에 접근하고, 사이트는 기본 사용 정보와 사용자가 브라우저에서 열 수 있는 로그인 링크를 돌려줌
      사용자가 브라우저에서 인증하고, 콜백이 고유하고 짧게 사는 일회성 토큰을 돌려주며, 이후 사이트 요청에서 이를 교환하는 방식이면 좋겠음
      이렇게 하면 사용자를 빠르게 인증하면서 작업 중 세션 상태도 유지할 수 있음
    • Microsoft Entra, 즉 Azure AD 팀과 소통이 있는지 궁금함
      곧 기대해도 되는지, 아니면 시간이 꽤 걸릴지 알고 싶음
    • 출시 축하함
      주 사용 사례는 회사 직원들로 보이는데, 고객이나 프리미엄 무료 사용자처럼 중앙화되지 않은 사용자에게도 비슷한 가치가 있는지 궁금함
      잘 떠오르지 않아서 내가 뭘 놓치고 있는지 알고 싶었고, 관련 답변은 여기서 본 듯함: https://news.ycombinator.com/item?id=48594381
    • 아직 실제로 사용 가능한 건 아니고 SEP 단계인지 확인하고 싶음

  • 이건 정말 훌륭함
    지난 몇 달간 MCP 쪽 사람들과 몇 가지 SEP와 Go 실험용 SDK를 함께 다룰 수 있어 운이 좋았음
    예전에는 “그냥 API잖아”, “또 추상화를 하나 만들었네”라고 하던 회의론자였음
    사람들이 놓치는 건 MCP의 “P”가 오해를 만든다는 점임
    전통적인 앱을 만들 때는 폼, UI, 요청/응답 처리, 양방향 채널, 장시간 작업, 인증 등을 만들어야 함
    MCP를 쓰면 이 공통 계층의 80%가 처리되므로, MCP는 프로토콜이기도 하지만 사실상 앱 프레임워크에 가까움
    통합 인증은 엄청난 강화이고, 앞으로 더 멋진 것들이 기대됨

  • 내가 만든 작업이 밖에서 보이는 건 꽤 신기함
    Atlassian에서 이 흐름의 RAS 쪽 구현을 맡았음
    CIMD, 더 나은 테넌시 지원 등 이 흐름에는 분명 반복 개선이 있을 것임
    Anthropic, Okta, Atlassian에서 이걸 전달한 사람들은 모두 훌륭했음

  • 웹을 지원해서 그냥 장기 쿠키를 발급할 수 있게 해주면 좋겠음
    OAuth 서버 없이 이걸 하려고 OAuth 핸드셰이크로 쿠키를 통과시키도록 명세를 해킹했음
    이런 걸 허용하지 않으려는 건 정말 답답함
    쿠키가 없으면 웹페이지를 열고, 쿠키가 설정되면 닫고 저장하면 됨
    MCP에 대해 80쪽짜리 미니북까지 썼지만, 여전히 끝없이 답답함

    • MCP 프로젝트의 리드 메인테이너 중 한 명인데, 이 방식은 여러 시나리오에서 확장되지 않음
      사용성과 보안 양쪽 모두에서 문제가 있고, 쿠키는 브라우저를 위해 만들어진 것임
      MCP 서버와 클라이언트는 브라우저가 보장되지 않는 환경에서 동작하는 경우가 많음
    • 그건 그냥 자격 증명을 도난당하게 해달라는 것에 가까움
      장기 자격 증명은 큰 책임 부담임

  • 여러 번 읽어봤는데 확실히 유용함
    감사와 접근 제어를 ID 제공자 한곳에 중앙화하고, 필요할 때 토큰 교환을 맡는 프록시 API 게이트웨이처럼 ID 제공자가 동작할 수도 있음
    이 분야의 다른 플레이어들도 채택한 접근임
    개인적으로는 ID 제공자가 내가 인지하지 못한 상태에서 내 권한을 클라이언트에 위임한다는 점이 조금 불편함
    브라우저에서 사용자가 존재하는 흐름에 너무 익숙해서 그런지도 모르겠고, 점점 머신을 위한 접근 중앙화로 진화하는 느낌임
    엔터프라이즈 환경에서는 신원이 개인보다 회사에 속하므로 받아들일 만할 수 있음
    하지만 고객 ID 쪽에 통합하는 건 전혀 다른 난제이고, ID 제공자·클라이언트·리소스 인가 서버 사이에 이런 신뢰를 만들기는 아마 쉽지 않음

    • 이 통합이 소비자 영역에서 동작하지 못하게 하는 이론적 장벽은 없음
      예를 들어 GitHub에 로그인되어 있으면 Sentry에도 자동 로그인되게 하는 식의 신뢰 관계를 만들면 됨
      앞으로 할 일이 더 많지만, 현재 가장 명확한 사용 사례는 말한 대로 엔터프라이즈임
      관리자는 개별 직원이 여기저기 클릭하면서 임의의 자격 증명을 고르게 하고 싶어 하지 않음

  • C1에서는 내부 MCP 사용과 제품 내 MCP Gateway 양쪽에서 MCP 인증이 큰 골칫거리였기 때문에, 이게 들어오는 게 매우 반가움
    오늘 C1이 EMA ID 제공자로 동작하는 지원을 출시했고, 짧게 사는 범위 제한 토큰을 발급함
    이제 Linear와 우리가 쓰는 다른 MCP들에 연결해 반복적인 OAuth 흐름에서 벗어나고 싶음
    Claude는 내장 커넥터 일부, 적어도 Slack에서는 이런 걸 마법처럼 해왔고 경험이 꽤 좋음
    공개하자면 C1의 VPE이고, 깊게 파고드는 사람을 위해 접근 방식을 문서화해 두었음: https://www.c1.ai/docs/product/admin/enterprise-managed-auth...

  • 이게 일반 OAuth보다 어떤 장점이 있는지 잘 이해가 안 됨
    인가 흐름 비교 예시가 필요할 것 같음

    • 일반 OAuth에서는 최종 사용자가 각 애플리케이션에 자기 데이터를 공유할지 개별적으로 동의함
      소비자 사용 사례, 즉 최종 사용자가 자기 데이터를 소유하는 경우에는 말이 됨
      하지만 많은 비즈니스 사용 사례에서는 데이터를 공유하고 접근을 통제해야 하는 주체가 최종 사용자가 아니라 회사임
      Acme 직원인 내가 Acme Google Drive 데이터를 Claude나 ChatGPT에 연결할지 결정해서는 안 되고, 그건 IT 부서가 결정해야 함
      Enterprise-Managed OAuth, 또는 Cross App Access(XAA)는 IT 관리자가 중앙에서 제어하는 공유 모델을 OAuth 프레임워크 안으로 가져와 기존 생태계와 함께 동작하게 함
      또 데이터 공유 동의 관리를 직원에서 IT 관리자로 옮기면 사용자 경험상 이점도 큼
      직원이 계정을 연결하려고 여러 OAuth 흐름을 거칠 필요가 없고, IT 관리자가 이미 공유 제어를 설정해둔 상태가 됨
      입사 첫날 Slack이 Zoom, Drive, Calendar 등에 이미 연결되어 있는 상황을 떠올리면 됨
    • 장점은 사용자가 어떤 앱들이 서로 자기 정보를 공유하도록 인가되는지 제어하거나 동의할 필요가 없다는 것임
      접근 위임 결정이 ID 제공자 정책 수준에서 내려지기 때문임
      사용자는 어떤 앱이나 서비스가 자기 정보를 공유하도록 허가됐는지 영영 모를 수도 있음
      잠깐, 그게 정말 장점인가? ;-)
답변달기