Kaynaklar ve kapsamlar

Microsoft kimlik platformu kaynaklara erişmek için kapsam odaklı bir model kullanır. Burada kaynak, Erişim Belirtecinin alıcısı olabilecek herhangi bir uygulamayı (MS Graph API veya kendi web API'niz gibi) ifade eder ve bir kapsam("izin") erişim belirteci tarafından bir kaynağın haklara sahip olduğu her yönü ifade eder.

MSAL.js'daki Erişim Belirteci isteklerinin kapsam başına kaynak başına olması amaçlanıyor. Bu, A kaynağı için kapsamına sahip bir scp1 istendiğini gösterir:

  • scp2 kapsamına sahip A kaynağına erişmek için kullanılamaz ve,
  • B kaynağına hiçbir kapsamda erişmek için kullanılamaz.

Erişim Belirtecinin hedeflenen alıcısı talep tarafından aud temsil edilir; talebin değeri aud kaynak APP ID URI'si ile eşleşmemesi durumunda belirtecin geçersiz olarak kabul edilmesi gerekir. Benzer şekilde, Erişim Belirteci'nin verdiği izinler de talep tarafından scp temsil edilir. Daha fazla bilgi için bkz. Erişim Belirteci talepleri .

Varsayılan kapsamlar

MSAL.js varsayılan olarak her isteğe openid, profile ve offline_access kapsamlarını ekler. Bu kapsamlar, bir yenileme belirteci ve hesap nesnesini kullanıcının bilgileriyle doldurmak için kullanılan kimlik belirteci taleplerini almak için gereklidir.

Birden çok kaynakla çalışma

Birden çok kaynağa erişmeniz gerektiğinde, her bir kaynak için ayrı bir belirteç isteği başlatın:

// "User.Read" stands as shorthand for "graph.microsoft.com/User.Read"
const graphToken = await msalInstance.acquireTokenSilent({
     scopes: [ "User.Read" ]
});
const customApiToken = await msalInstance.acquireTokenSilent({
     scopes: [ "api://<myCustomApiClientId>/My.Scope" ]
});

Aynı kaynak için birden çok kapsam isteyebileceğinizi unutmayın (örneğinUser.Read, User.Write ve Calendar.ReadMS Graph API için).

const graphToken = await msalInstance.acquireTokenSilent({
     scopes: [ "User.Read", "User.Write", "Calendar.Read" ] // all MS Graph API scopes
});

Belirteç isteğinizde yanlışlıkla birden çok kaynak geçirmeniz durumunda, alacağınız belirteç yalnızca ilk kaynak için verilir.

// you will only receive a token for MS GRAPH API's "User.Read" scope here
const myToken = await msalInstance.acquireTokenSilent({
     scopes: [ "User.Read", "api://<myCustomApiClientId>/My.Scope" ]
});

Microsoft Entra ID doğrudan uygulama kaydında ayarlanan kapsamlara (izinler) statik kapsamlar adı verilir. Yalnızca kod içinde tanımlanan diğer kapsamlar dinamik kapsamlar olarak adlandırılır. Bunun,MSAL.jsoturum açma (örneğin loginPopup, loginRedirect) ve acquireToken (yani acquireTokenPopup, acquireTokenRedirect, acquireTokenSilent) yöntemleri üzerinde etkileri vardır. Consider:

 const loginRequest = {
      scopes: [ "openid", "profile", "User.Read" ]
 };
 const tokenRequest = {
      scopes: [ "Mail.Read" ]
 };
 // will return an ID Token and an Access Token with scopes: "openid", "profile" and "User.Read"
 msalInstance.loginPopup(loginRequest);
 // will fail and fallback to an interactive method prompting a consent screen
 // after consent, the received token will be issued for "openid", "profile" ,"User.Read" and "Mail.Read" combined
 msalInstance.acquireTokenSilent(tokenRequest);

Yukarıdaki kod parçacığında, kimliği doğrulayıp kapsamına sahip bir Kimlik Belirteci ve User.Read aldıktan sonra kullanıcıdan onay istenir. Daha sonra, için User.Read isterlerse, bir daha onay istenmeyecektir (başka bir deyişle, sessizce belirteç alabilirler).

Öte yandan, kullanıcı kimlik doğrulama aşamasında Mail.Read için onay vermediğinden, Mail.Read kapsamı için bir Erişim Belirteci isterken onayı istenecektir. Alınan belirteç, önceden onaylanan tüm kapsamları (belirli bir kaynak için) içerir, bu nedenle artımlı onay terimini içerir.

Biraz farklı bir durum düşünün:

 const loginRequest = {
      scopes: [ "openid", "profile", "User.Read" ],
      extraScopesToConsent: [ "api://<myCustomApiClientId>/My.Scope"]
 };
 const tokenRequest = {
      scopes: [ "Mail.Read" ]
 };
 const anotherTokenRequest = {
      scopes: [ "api://<myCustomApiClientId>/My.Scope" ]
 }
 // will return an ID Token and an Access Token with scopes: "openid", "profile" and "User.Read"
 msalInstance.loginPopup(loginRequest);
 // will fail with InteractionRequiredError due to lack of consent for "Mail.Read" scope. You should fallback to an interactive method in this case.
 msalInstance.acquireTokenSilent(tokenRequest);
 // will succeed and return an Access Token with scope "api://<myCustomApiClientId>/My.Scope"
 msalInstance.acquireTokenSilent(anotherTokenRequest);

Yukarıdaki kod parçacığında, kullanıcı hem User.Read hem de api://<myCustomApiClientId>/My.Scope kapsamlarına onay verse bile, kaynak başına kapsam ilkesi uyarınca yalnızca MS Graph API için bir Erişim Belirteci alırlar. Ancak, zaten onay verdikleri içinapi://<myCustomApiClientId>/My.Scope, daha sonra bu kaynak/kapsam için sessizce bir Erişim Belirteci alabilirler.

Microsoft Entra ID'de onay, uygulamanın kullanım ömründen daha uzun sürer. Bu, bir kaynak için Erişim Belirteci istediğinizde, o sırada hangi kapsamın istendiğine bakılmaksızın, bu kaynak için daha önce onayladığınız tüm kapsamların döndürüleceği anlamına gelir. Başka bir deyişle, bugün User.Read ve Mail.Read için onay verirseniz ve yarın uygulamanızın yeni bir örneğini çalıştırıp yalnızca User.Read için bir Erişim Belirteci isterseniz, yine de her ikisiUser.Read ve Mail.Read için verilmiş bir belirteç almaya devam edersiniz. Daha fazla bilgi için İzinler ve Onay bölümüne bakın.

  • Last updated on