You cannot see this page without javascript.

2016.01.18 10:21

MS Windows OAuth 2.0

조회 수 324 추천 수 0 댓글 0

OAuth 2.0

 

Live Connect는 사용자 인증을 위해 OAuth 2.0 프로토콜을 구현합니다. 이 항목에서는 Live Connect에서 사용하는 권한 부여 흐름 및 지원되는 확장 매개 변수에 대해 설명합니다.

이 항목에서는 사용자가 OAuth 2.0과 OAuth 용어에 익숙하다고 가정합니다. OAuth에 익숙하지 않은 경우 먼저 OAuth 2.0 사양을 확인해 보거나, 낯선 용어나 개념이 나오면 찾아볼 것을 권장합니다.

 

지원되는 OAuth 흐름

Live Connect는 다음과 같은 권한 부여 흐름을 지원합니다.

암시적 허용 흐름

암시적 허용 흐름은 웹 기반 앱 및 데스크톱 앱에서 모두 사용될 수 있습니다. 이 흐름에서 클라이언트는 https://login.live.com/oauth20_authorize.srf에 대해 request_type=token으로 권한 부여를 요청합니다. 이는 표준 OAuth 2.0 흐름으로서 OAuth 2.0 사양의 암시적 허용 섹션에 자세히 정의되어 있습니다.

다음 다이어그램은 암시적 허용 흐름의 작동 방식을 보여 줍니다.

OAuth 2.0 암시적 허용 흐름 다이어그램.
  1. 클라이언트는 리소스 소유자의 사용자 에이전트를 Live Connect 권한 부여 끝점으로 보내고 다음 형식의 URL을 사용하여 흐름을 시작합니다.

     
     
    https://login.live.com/oauth20_authorize.srf?client_id=CLIENT_ID&scope=SCOPES&response_type=token&redirect_uri=REDIRECT_URI
    

    이 URL에는 클라이언트 ID, 요청 범위, 그리고 액세스가 허용 또는 거부된 후 권한 부여 웹 서비스가 사용자 에이전트를 보내는 리디렉션 URI(Uniform Resource Identifier)가 포함됩니다.

    참고  암시적 허용 흐름(response_type=token)을 사용하는 경우 wl.offline_access 범위를 포함하지 마세요.

  2. 사용자는 로그인 자격 증명에 대한 프롬프트가 나타나면 클라이언트 액세스 요청을 허용 또는 거부합니다.

  3. 사용자가 액세스를 허용하면 Live Connect 권한 부여 서버는 초기 요청에서 제공된 리디렉션 URI를 사용해 사용자 에이전트를 클라이언트로 리디렉션합니다. 리디렉션 URI의 URI 조각에는 액세스 토큰이 포함됩니다. 예:http://contoso.com/Callback.htm#access_token=ACCESS_TOKEN.

  4. 사용자 에이전트는 Contoso 웹 서버에 대한 요청을 만들어 리디렉션 지침을 따릅니다. 사용자 에이전트는 URI 조각을 로컬에 보유하지만, 서버에 대한 요청에는 포함하지 않습니다.

  5. Contoso 서버는 사용자 에이전트가 보유했던 조각을 포함한 전체 리디렉션 URI에 액세스할 수 있는 웹 페이지(대개 포함 스크립트가 있는 HTML 문서)를 반환합니다. 스크립트는 또한 액세스 토큰 및 조각에 포함된 기타 매개 변수를 추출할 수 있습니다.

    사용자 에이전트는 웹 서버에서 제공한 스크립트를 로컬에서 실행하여 액세스 토큰을 추출하고 이를 클라이언트에 전달합니다.

맨 위로

인증 코드 허용 흐름

인증 코드 허용 흐름에서 클라이언트는 request_type=code를 사용해 권한 부여를 요청합니다. 이는 표준 OAuth 2.0 흐름으로서 OAuth 2.0 사양의 인증 코드 허용 섹션에 자세히 정의되어 있습니다. 자세한 내용은 서버 쪽 시나리오를 참조하세요.

다음 다이어그램은 인증 코드 허용 흐름의 작동 방식을 보여 줍니다.

OAuth 2.0 인증 코드 허용 흐름 다이어그램.
  1. 클라이언트는 리소스 소유자의 사용자 에이전트를 Live Connect 권한 부여 끝점으로 보내고 다음 형식의 URL을 사용하여 흐름을 시작합니다.

     
     
    https://login.live.com/oauth20_authorize.srf?client_id=CLIENT_ID&scope=SCOPES&response_type=code&redirect_uri=REDIRECT_URI
    

    이 URL에는 클라이언트 ID, 요청 범위, 그리고 액세스가 허용 또는 거부된 후 권한 부여 웹 서비스가 사용자 에이전트를 보내는 리디렉션 URI가 포함됩니다.

  2. 권한 부여 서버는 사용자 에이전트를 통해 리소스 소유자를 인증하고, 리소스 소유자가 클라이언트 액세스 요청을 허용하는지 아니면 거부하는지를 확인합니다.

  3. 리소스 소유자가 액세스를 허용하면 Live Connect 권한 부여 서버는 초기 요청에서 제공된 리디렉션 URI를 사용해 사용자 에이전트를 클라이언트로 리디렉션합니다.

  4. 사용자 에이전트는 인증 코드 및 클라이언트가 제공한 로컬 상태를 포함하는 리디렉션 URI로 클라이언트를 호출합니다. 예:http://contoso.com/Callback.htm?code=AUTHORIZATION_CODE.

  5. 클라이언트는 인증을 위한 클라이언트 자격 증명을 사용해 권한 부여 서버의 토큰 끝점에서 액세스 토큰을 요청하며, 이전 단계에서 받은 인증 코드를 포함합니다. 클라이언트는 검증을 위한 인증 코드를 얻는 데 사용된 리디렉션 URI를 포함합니다. 요청 URL 형식은 다음과 같습니다.

     
     
    POST https://login.live.com/oauth20_token.srf
    
    Content-type: application/x-www-form-urlencoded
    
    client_id=CLIENT_ID&redirect_uri=REDIRECT_URI&client_secret=CLIENT_SECRET&code=AUTHORIZATION_CODE&grant_type=authorization_code
    

    Live Connect 권한 부여 서버는 클라이언트 자격 증명 및 인증 코드의 유효성을 확인하고, 수신한 리디렉션 URI가 3단계에서 클라이언트를 리디렉션하는 데 사용된 URI와 일치하는지 확인합니다.

  6. 자격 증명이 유효하면 권한 부여 서버는 액세스 토큰을 반환하여 응답합니다. wl.offline_access 범위가 요청된 경우 새로 고침 토큰이 반환됩니다. 액세스 토큰을 새로 고치려면 클라이언트는 다음 URL을 요청해야 합니다.

     
     
    POST https://login.live.com/oauth20_token.srf
    
    Content-type: application/x-www-form-urlencoded
    
    client_id=CLIENT_ID&client_secret=CLIENT_SECRET&redirect_uri=REDIRECT_URI&grant_type=refresh_token&refresh_token=REFRESH_TOKEN
    

    데스크톱 및 모바일 앱 개발자의 편의를 위해 Live Connect OAuth 2.0 구현에서는 다음의 특수 리디렉션 URL을 제공합니다. https://login.live.com/oauth20_desktop.srf. 이를 통해 웹 브라우저 컨트롤(예: Java 앱, Cocoa 앱 또는 .NET 앱)을 호스트할 수 있는 앱은 사용자가 언제 https://login.live.com/oauth20_desktop.srf#access_token=ACCESS_TOKEN으로 리디렉션되는지 수신 대기한 다음, 선택한 클라이언트 플랫폼에서 사용 가능한 메커니즘을 통해 URL 끝에서 액세스 토큰을 검색함으로써 사용자의 동의 후 리디렉션을 처리할 수 있습니다. 앱은 또한 액세스 토큰을 새로 고쳐야 하기 때문에, Live Connect 앱 관리 사이트에서는 앱을 모바일 클라이언트 앱으로 표시하도록 허용합니다. 이 마커가 지정되고 특수 리디렉션 URL(https://login.live.com/oauth20_desktop.srf)이 사용되면 액세스 토큰을 새로 고치기 위해 클라이언트 암호가 필요하지 않습니다. 이 경우 액세스 토큰을 새로 고치기 위한 URL은 다음과 같습니다.

     
     
    POST https://login.live.com/oauth20_token.srf
    
    Content-type: application/x-www-form-urlencoded
    
    client_id=CLIENT_ID&redirect_uri=https://login.live.com/oauth20_desktop.srf&grant_type=refresh_token&refresh_token=REFRESH_TOKEN
    
    

맨 위로

로그인 제어 흐름

로그인 제어 흐름은 Live Connect에만 있습니다. 로그인 제어 흐름은 Live Connect 로그인 제어를 사용해 앱에 대한 로그인과 동의를 간소화합니다. 브라우저 기반 앱에서 사용하도록 설계된 이 흐름은 앱에서 서버 쪽 논리를 사용하도록 요구하지 않습니다. HTTP 요청을 사용해 동의 서비스를 직접 호출하기보다는 JavaScript API(WL.login 메서드)를 사용하여 또는 HTML 컨트롤을 포함하여(WL.ui 메서드를 호출하여) 흐름을 시작할 수 있습니다. 로그인 제어 흐름은 Live Connect 및 비 Microsoft 웹앱 전체에서 원활한 single sign-in을 지원하는 유일한 웹 흐름입니다. Single sign-in은 Live Connect에 이미 로그인한 사용자가 다른 웹 사이트로 가면 Live Connect 계정을 기반으로 그곳에 자동으로 로그인될 수 있는 메커니즘입니다. 사용자는 각 웹 사이트에서 옵트인(opt in) 기반으로 이 로그인 동작을 제어할 수 있습니다.

로그인 제어 흐름은 암시적 허용 흐름의 한 변형입니다. 이 둘의 주요 차이점은, 로그인 제어 흐름은 클라이언트 웹 페이지에 포함된 보이지 않는 HTML iframe 요소를 사용해 구현되며, 암시적 허용 흐름은 클라이언트 앱에 의해 구현되어야 한다는 것입니다.

중요   로그인 제어 흐름에는 서버 쪽 처리가 필요하지 않으므로 앱은 페이지가 로드된 후에만 사용자 정보에 액세스할 수 있습니다.

로그인 제어 흐름은 다음과 같이 작동합니다.

  1. 클라이언트는 리소스 소유자의 사용자 에이전트를 Live Connect 권한 부여 끝점으로 보내고 다음 형식의 URL을 사용하여 흐름을 시작합니다.https://login.live.com/oauth20_authorize.srf?client_id=CLIENT_ID&
 scope=SCOPES&response_type=code&redirect_uri=REDIRECT_URI.

    이 URL에는 클라이언트 ID, 요청 범위, 로컬 상태, 그리고 액세스가 허용 또는 거부된 후 권한 부여 웹 서비스가 사용자 에이전트를 보내는 리디렉션 URI가 포함됩니다.

  2. 사용자는 자격 증명에 대한 프롬프트가 나타나면 클라이언트 액세스 요청을 허용 또는 거부합니다.

맨 위로

OAuth 권한 부여 요청 매개 변수

다음 표는 Live Connect에서 사용하는 OAuth 권한 부여 요청 매개 변수를 보여 줍니다.

매개 변수 참고

client_id

앱의 클라이언트 ID.

display

권한 부여 페이지에 사용할 디스플레이 유형. 유효한 값은 "popup", "touch", "page" 또는 "none"입니다.

locale

선택 사항. 동의 UI의 지역화 방법을 결정하는 시장 문자열. 이 매개 변수의 값이 누락되거나 잘못되면 내부 알고리즘을 사용해 market 값이 결정됩니다.

redirect_uri

OAuth 2.0 사양에 설명된 끝점과 같음.

response_type

권한 부여 서버의 응답에서 반환될 데이터 형식. 유효한 값은 "code" 또는 "token"입니다.

scope

OAuth 2.0 사양에 설명된 scope 매개 변수와 같음.

state

OAuth 2.0 사양에 설명된 state 매개 변수와 같음.

 

맨 위로

OAuth 요청 및 응답 매개 변수

다음 표는 Live Connect에서 사용하는 OAuth 요청 및 응답 매개 변수를 보여 줍니다.

매개 변수 참고

client_id

앱의 클라이언트 ID.

client secret

앱의 클라이언트 암호.

grant_type

서버에서 반환하는 권한 부여 유형. 유효한 값은 "authorization_code" 또는 "refresh_token"입니다.

locale

선택 사항. 동의 UI의 지역화 방법을 결정하는 시장 문자열. 이 매개 변수의 값이 누락되거나 잘못되면 내부 알고리즘을 사용해 market 값이 결정됩니다.

redirect_uri

OAuth 2.0 사양에 설명된 끝점과 같음.

response_type

권한 부여 서버의 응답에서 반환될 데이터 형식. 유효한 값은 "code" 또는 "token"입니다.

scope

OAuth 2.0

 

Live Connect는 사용자 인증을 위해 OAuth 2.0 프로토콜을 구현합니다. 이 항목에서는 Live Connect에서 사용하는 권한 부여 흐름 및 지원되는 확장 매개 변수에 대해 설명합니다.

이 항목에서는 사용자가 OAuth 2.0과 OAuth 용어에 익숙하다고 가정합니다. OAuth에 익숙하지 않은 경우 먼저 OAuth 2.0 사양을 확인해 보거나, 낯선 용어나 개념이 나오면 찾아볼 것을 권장합니다.

 

지원되는 OAuth 흐름

Live Connect는 다음과 같은 권한 부여 흐름을 지원합니다.

암시적 허용 흐름

암시적 허용 흐름은 웹 기반 앱 및 데스크톱 앱에서 모두 사용될 수 있습니다. 이 흐름에서 클라이언트는 https://login.live.com/oauth20_authorize.srf에 대해 request_type=token으로 권한 부여를 요청합니다. 이는 표준 OAuth 2.0 흐름으로서 OAuth 2.0 사양의 암시적 허용 섹션에 자세히 정의되어 있습니다.

다음 다이어그램은 암시적 허용 흐름의 작동 방식을 보여 줍니다.

OAuth 2.0 암시적 허용 흐름 다이어그램.
  1. 클라이언트는 리소스 소유자의 사용자 에이전트를 Live Connect 권한 부여 끝점으로 보내고 다음 형식의 URL을 사용하여 흐름을 시작합니다.

     
     
    https://login.live.com/oauth20_authorize.srf?client_id=CLIENT_ID&scope=SCOPES&response_type=token&redirect_uri=REDIRECT_URI
    

    이 URL에는 클라이언트 ID, 요청 범위, 그리고 액세스가 허용 또는 거부된 후 권한 부여 웹 서비스가 사용자 에이전트를 보내는 리디렉션 URI(Uniform Resource Identifier)가 포함됩니다.

    참고  암시적 허용 흐름(response_type=token)을 사용하는 경우 wl.offline_access 범위를 포함하지 마세요.

  2. 사용자는 로그인 자격 증명에 대한 프롬프트가 나타나면 클라이언트 액세스 요청을 허용 또는 거부합니다.

  3. 사용자가 액세스를 허용하면 Live Connect 권한 부여 서버는 초기 요청에서 제공된 리디렉션 URI를 사용해 사용자 에이전트를 클라이언트로 리디렉션합니다. 리디렉션 URI의 URI 조각에는 액세스 토큰이 포함됩니다. 예:http://contoso.com/Callback.htm#access_token=ACCESS_TOKEN.

  4. 사용자 에이전트는 Contoso 웹 서버에 대한 요청을 만들어 리디렉션 지침을 따릅니다. 사용자 에이전트는 URI 조각을 로컬에 보유하지만, 서버에 대한 요청에는 포함하지 않습니다.

  5. Contoso 서버는 사용자 에이전트가 보유했던 조각을 포함한 전체 리디렉션 URI에 액세스할 수 있는 웹 페이지(대개 포함 스크립트가 있는 HTML 문서)를 반환합니다. 스크립트는 또한 액세스 토큰 및 조각에 포함된 기타 매개 변수를 추출할 수 있습니다.

    사용자 에이전트는 웹 서버에서 제공한 스크립트를 로컬에서 실행하여 액세스 토큰을 추출하고 이를 클라이언트에 전달합니다.

맨 위로

인증 코드 허용 흐름

인증 코드 허용 흐름에서 클라이언트는 request_type=code를 사용해 권한 부여를 요청합니다. 이는 표준 OAuth 2.0 흐름으로서 OAuth 2.0 사양의 인증 코드 허용 섹션에 자세히 정의되어 있습니다. 자세한 내용은 서버 쪽 시나리오를 참조하세요.

다음 다이어그램은 인증 코드 허용 흐름의 작동 방식을 보여 줍니다.

OAuth 2.0 인증 코드 허용 흐름 다이어그램.
  1. 클라이언트는 리소스 소유자의 사용자 에이전트를 Live Connect 권한 부여 끝점으로 보내고 다음 형식의 URL을 사용하여 흐름을 시작합니다.

     
     
    https://login.live.com/oauth20_authorize.srf?client_id=CLIENT_ID&scope=SCOPES&response_type=code&redirect_uri=REDIRECT_URI
    

    이 URL에는 클라이언트 ID, 요청 범위, 그리고 액세스가 허용 또는 거부된 후 권한 부여 웹 서비스가 사용자 에이전트를 보내는 리디렉션 URI가 포함됩니다.

  2. 권한 부여 서버는 사용자 에이전트를 통해 리소스 소유자를 인증하고, 리소스 소유자가 클라이언트 액세스 요청을 허용하는지 아니면 거부하는지를 확인합니다.

  3. 리소스 소유자가 액세스를 허용하면 Live Connect 권한 부여 서버는 초기 요청에서 제공된 리디렉션 URI를 사용해 사용자 에이전트를 클라이언트로 리디렉션합니다.

  4. 사용자 에이전트는 인증 코드 및 클라이언트가 제공한 로컬 상태를 포함하는 리디렉션 URI로 클라이언트를 호출합니다. 예:http://contoso.com/Callback.htm?code=AUTHORIZATION_CODE.

  5. 클라이언트는 인증을 위한 클라이언트 자격 증명을 사용해 권한 부여 서버의 토큰 끝점에서 액세스 토큰을 요청하며, 이전 단계에서 받은 인증 코드를 포함합니다. 클라이언트는 검증을 위한 인증 코드를 얻는 데 사용된 리디렉션 URI를 포함합니다. 요청 URL 형식은 다음과 같습니다.

     
     
    POST https://login.live.com/oauth20_token.srf
    
    Content-type: application/x-www-form-urlencoded
    
    client_id=CLIENT_ID&redirect_uri=REDIRECT_URI&client_secret=CLIENT_SECRET&code=AUTHORIZATION_CODE&grant_type=authorization_code
    

    Live Connect 권한 부여 서버는 클라이언트 자격 증명 및 인증 코드의 유효성을 확인하고, 수신한 리디렉션 URI가 3단계에서 클라이언트를 리디렉션하는 데 사용된 URI와 일치하는지 확인합니다.

  6. 자격 증명이 유효하면 권한 부여 서버는 액세스 토큰을 반환하여 응답합니다. wl.offline_access 범위가 요청된 경우 새로 고침 토큰이 반환됩니다. 액세스 토큰을 새로 고치려면 클라이언트는 다음 URL을 요청해야 합니다.

     
     
    POST https://login.live.com/oauth20_token.srf
    
    Content-type: application/x-www-form-urlencoded
    
    client_id=CLIENT_ID&client_secret=CLIENT_SECRET&redirect_uri=REDIRECT_URI&grant_type=refresh_token&refresh_token=REFRESH_TOKEN
    

    데스크톱 및 모바일 앱 개발자의 편의를 위해 Live Connect OAuth 2.0 구현에서는 다음의 특수 리디렉션 URL을 제공합니다. https://login.live.com/oauth20_desktop.srf. 이를 통해 웹 브라우저 컨트롤(예: Java 앱, Cocoa 앱 또는 .NET 앱)을 호스트할 수 있는 앱은 사용자가 언제 https://login.live.com/oauth20_desktop.srf#access_token=ACCESS_TOKEN으로 리디렉션되는지 수신 대기한 다음, 선택한 클라이언트 플랫폼에서 사용 가능한 메커니즘을 통해 URL 끝에서 액세스 토큰을 검색함으로써 사용자의 동의 후 리디렉션을 처리할 수 있습니다. 앱은 또한 액세스 토큰을 새로 고쳐야 하기 때문에, Live Connect 앱 관리 사이트에서는 앱을 모바일 클라이언트 앱으로 표시하도록 허용합니다. 이 마커가 지정되고 특수 리디렉션 URL(https://login.live.com/oauth20_desktop.srf)이 사용되면 액세스 토큰을 새로 고치기 위해 클라이언트 암호가 필요하지 않습니다. 이 경우 액세스 토큰을 새로 고치기 위한 URL은 다음과 같습니다.

     
     
    POST https://login.live.com/oauth20_token.srf
    
    Content-type: application/x-www-form-urlencoded
    
    client_id=CLIENT_ID&redirect_uri=https://login.live.com/oauth20_desktop.srf&grant_type=refresh_token&refresh_token=REFRESH_TOKEN
    
    

맨 위로

로그인 제어 흐름

로그인 제어 흐름은 Live Connect에만 있습니다. 로그인 제어 흐름은 Live Connect 로그인 제어를 사용해 앱에 대한 로그인과 동의를 간소화합니다. 브라우저 기반 앱에서 사용하도록 설계된 이 흐름은 앱에서 서버 쪽 논리를 사용하도록 요구하지 않습니다. HTTP 요청을 사용해 동의 서비스를 직접 호출하기보다는 JavaScript API(WL.login 메서드)를 사용하여 또는 HTML 컨트롤을 포함하여(WL.ui 메서드를 호출하여) 흐름을 시작할 수 있습니다. 로그인 제어 흐름은 Live Connect 및 비 Microsoft 웹앱 전체에서 원활한 single sign-in을 지원하는 유일한 웹 흐름입니다. Single sign-in은 Live Connect에 이미 로그인한 사용자가 다른 웹 사이트로 가면 Live Connect 계정을 기반으로 그곳에 자동으로 로그인될 수 있는 메커니즘입니다. 사용자는 각 웹 사이트에서 옵트인(opt in) 기반으로 이 로그인 동작을 제어할 수 있습니다.

로그인 제어 흐름은 암시적 허용 흐름의 한 변형입니다. 이 둘의 주요 차이점은, 로그인 제어 흐름은 클라이언트 웹 페이지에 포함된 보이지 않는 HTML iframe 요소를 사용해 구현되며, 암시적 허용 흐름은 클라이언트 앱에 의해 구현되어야 한다는 것입니다.

중요   로그인 제어 흐름에는 서버 쪽 처리가 필요하지 않으므로 앱은 페이지가 로드된 후에만 사용자 정보에 액세스할 수 있습니다.

로그인 제어 흐름은 다음과 같이 작동합니다.

  1. 클라이언트는 리소스 소유자의 사용자 에이전트를 Live Connect 권한 부여 끝점으로 보내고 다음 형식의 URL을 사용하여 흐름을 시작합니다.https://login.live.com/oauth20_authorize.srf?client_id=CLIENT_ID&
 scope=SCOPES&response_type=code&redirect_uri=REDIRECT_URI.

    이 URL에는 클라이언트 ID, 요청 범위, 로컬 상태, 그리고 액세스가 허용 또는 거부된 후 권한 부여 웹 서비스가 사용자 에이전트를 보내는 리디렉션 URI가 포함됩니다.

  2. 사용자는 자격 증명에 대한 프롬프트가 나타나면 클라이언트 액세스 요청을 허용 또는 거부합니다.

맨 위로

OAuth 권한 부여 요청 매개 변수

다음 표는 Live Connect에서 사용하는 OAuth 권한 부여 요청 매개 변수를 보여 줍니다.

매개 변수 참고

client_id

앱의 클라이언트 ID.

display

권한 부여 페이지에 사용할 디스플레이 유형. 유효한 값은 "popup", "touch", "page" 또는 "none"입니다.

locale

선택 사항. 동의 UI의 지역화 방법을 결정하는 시장 문자열. 이 매개 변수의 값이 누락되거나 잘못되면 내부 알고리즘을 사용해 market 값이 결정됩니다.

redirect_uri

OAuth 2.0 사양에 설명된 끝점과 같음.

response_type

권한 부여 서버의 응답에서 반환될 데이터 형식. 유효한 값은 "code" 또는 "token"입니다.

scope

OAuth 2.0 사양에 설명된 scope 매개 변수와 같음.

state

OAuth 2.0 사양에 설명된 state 매개 변수와 같음.

 

맨 위로

OAuth 요청 및 응답 매개 변수

다음 표는 Live Connect에서 사용하는 OAuth 요청 및 응답 매개 변수를 보여 줍니다.

매개 변수 참고

client_id

앱의 클라이언트 ID.

client secret

앱의 클라이언트 암호.

grant_type

서버에서 반환하는 권한 부여 유형. 유효한 값은 "authorization_code" 또는 "refresh_token"입니다.

locale

선택 사항. 동의 UI의 지역화 방법을 결정하는 시장 문자열. 이 매개 변수의 값이 누락되거나 잘못되면 내부 알고리즘을 사용해 market 값이 결정됩니다.

redirect_uri

OAuth 2.0 사양에 설명된 끝점과 같음.

response_type

권한 부여 서버의 응답에서 반환될 데이터 형식. 유효한 값은 "code" 또는 "token"입니다.

scope

OAuth 2.0 사양에 설명된 scope 매개 변수와 같음.

state

OAuth 2.0 사양에 설명된 state 매개 변수와 같음.

display

권한 부여 페이지에 사용할 디스플레이 유형. 유효한 값은 "popup", "touch", "page" 또는 "none"입니다.

 

다음 표는 Live Connect에서 사용하는 OAuth 응답 매개 변수를 보여 줍니다.

매개 변수 참고

access_token

OAuth 2.0 사양에 설명된 access_token 매개 변수와 같음.

authentication_token

앱의 인증 토큰.

code

OAuth 2.0 사양에 설명된 code 매개 변수와 같음.

expires_in

OAuth 2.0 사양에 설명된 expires_in 매개 변수와 같음.

refresh_token

OAuth 2.0 사양에 설명된 refresh_token 매개 변수와 같음.

scope

OAuth 2.0 사양에 설명된 scope 매개 변수와 같음.

state

OAuth 2.0 사양에 설명된 state 매개 변수와 같음.

token_type

권한 부여 서버의 응답에서 반환될 데이터 형식.

 

맨 위로

OAuth WRAP에서 OAuth 2.0으로 이동

Live Connect 버전 4.1은 사용자 인증과 동의, 그리고 액세스 토큰과 새로 고침 토큰 관리에 OAuth WRAP(Web Resource Authorization Protocol)의 구현을 사용합니다. Live Connect 버전 5는 OAuth 2.0의 구현을 위해 OAuth WRAP를 사용하지 않습니다. 또한 Live Connect 버전 4.1 서비스에 대한 액세스는 2012년 6월 25일에 종료됩니다. OAuth WRAP에서 OAuth 2.0으로 앱을 이동하려면 다음 정보를 알아야 합니다.

  • 사용자가 동의한 하나 이상의 범위를 포함하며 Live Connect 버전 4.1에 해당하는 새로 고침 토큰이 있는 앱은 Live Connect 버전 5에서도 동일한 동의된 범위를 포함하는 액세스 토큰을 얻기 위해 해당 새로 고침 토큰을 사용할 수 있습니다. 이를 통해 앱은 Live Connect 버전 5에서 사용자 정보에 액세스할 수 있으며, 사용자는 Live Connect 버전 4.1에서 이미 동의한 범위에 대해 다시 동의하지 않아도 됩니다. 예를 들어 사용자가 Live Connect 버전 4.1에서 WL_Photos.View 범위에 동의하였고 앱에 이 동의된 범위를 포함하는 새로 고침 토큰이 있는 경우, 앱은 Live Connect 버전 5에서 이 새로 고침 토큰을 사용해 WL_Photos.View 범위와 동일한 기능이 있는 범위를 포함하는 액세스 토큰을 얻을 수 있습니다. 그러면 앱은 Live Connect 버전 5에서 이 액세스 토큰을 사용해 동의한 사용자가 업로드한 사진 앨범과 동영상, 그리고 관련 태그 및 댓글에 액세스할 수 있습니다. Live Connect 버전 4.1에 해당하는 유효한 새로 고침 토큰이 있으며 사용자가 명시적으로 동의를 취소하지 않는다면, Live Connect 버전 4.1 서비스를 끈 후에도 Live Connect 버전 5에서 해당 새로 고침 토큰을 사용할 수 있습니다.
  • 앱은 Live Connect 버전 5를 사용해 Live Connect 버전 4.1에만 있는 특정 범위에 대한 동의를 사용자에게 요청할 수 없습니다.

자세한 내용은 Live Connect v4.1 앱을 v5.0으로 마이그레이션(영문)을 참조하세요.

state

OAuth 2.0 사양에 설명된 state 매개 변수와 같음.

display

권한 부여 페이지에 사용할 디스플레이 유형. 유효한 값은 "popup", "touch", "page" 또는 "none"입니다.

 

다음 표는 Live Connect에서 사용하는 OAuth 응답 매개 변수를 보여 줍니다.

매개 변수 참고

access_token

OAuth 2.0 사양에 설명된 access_token 매개 변수와 같음.

authentication_token

앱의 인증 토큰.

code

OAuth 2.0 사양에 설명된 code 매개 변수와 같음.

expires_in

OAuth 2.0 사양에 설명된 expires_in 매개 변수와 같음.

refresh_token

OAuth 2.0 사양에 설명된 refresh_token 매개 변수와 같음.

scope

OAuth 2.0 사양에 설명된 scope 매개 변수와 같음.

state

OAuth 2.0 사양에 설명된 state 매개 변수와 같음.

token_type

권한 부여 서버의 응답에서 반환될 데이터 형식.

 

맨 위로

OAuth WRAP에서 OAuth 2.0으로 이동

Live Connect 버전 4.1은 사용자 인증과 동의, 그리고 액세스 토큰과 새로 고침 토큰 관리에 OAuth WRAP(Web Resource Authorization Protocol)의 구현을 사용합니다. Live Connect 버전 5는 OAuth 2.0의 구현을 위해 OAuth WRAP를 사용하지 않습니다. 또한 Live Connect 버전 4.1 서비스에 대한 액세스는 2012년 6월 25일에 종료됩니다. OAuth WRAP에서 OAuth 2.0으로 앱을 이동하려면 다음 정보를 알아야 합니다.

  • 사용자가 동의한 하나 이상의 범위를 포함하며 Live Connect 버전 4.1에 해당하는 새로 고침 토큰이 있는 앱은 Live Connect 버전 5에서도 동일한 동의된 범위를 포함하는 액세스 토큰을 얻기 위해 해당 새로 고침 토큰을 사용할 수 있습니다. 이를 통해 앱은 Live Connect 버전 5에서 사용자 정보에 액세스할 수 있으며, 사용자는 Live Connect 버전 4.1에서 이미 동의한 범위에 대해 다시 동의하지 않아도 됩니다. 예를 들어 사용자가 Live Connect 버전 4.1에서 WL_Photos.View 범위에 동의하였고 앱에 이 동의된 범위를 포함하는 새로 고침 토큰이 있는 경우, 앱은 Live Connect 버전 5에서 이 새로 고침 토큰을 사용해 WL_Photos.View 범위와 동일한 기능이 있는 범위를 포함하는 액세스 토큰을 얻을 수 있습니다. 그러면 앱은 Live Connect 버전 5에서 이 액세스 토큰을 사용해 동의한 사용자가 업로드한 사진 앨범과 동영상, 그리고 관련 태그 및 댓글에 액세스할 수 있습니다. Live Connect 버전 4.1에 해당하는 유효한 새로 고침 토큰이 있으며 사용자가 명시적으로 동의를 취소하지 않는다면, Live Connect 버전 4.1 서비스를 끈 후에도 Live Connect 버전 5에서 해당 새로 고침 토큰을 사용할 수 있습니다.
  • 앱은 Live Connect 버전 5를 사용해 Live Connect 버전 4.1에만 있는 특정 범위에 대한 동의를 사용자에게 요청할 수 없습니다.

자세한 내용은 Live Connect v4.1 앱을 v5.0으로 마이그레이션(영문)을 참조하세요.