Microsoft kimlik platformu ve OAuth 2.0 Adına akışı

Makale
04/08/2024

Adına (OBO) akışı, başka bir web API'sini çağırmak için kendi kimliği dışında bir kimlik kullanan bir web API'sinin senaryosunu açıklar. OAuth'da temsilci olarak adlandırılan amaç, istek zinciri aracılığıyla kullanıcının kimliğini ve izinlerini geçirmektir.

Orta katman hizmetinin aşağı akış hizmetine kimliği doğrulanmış isteklerde bulunabilmesi için Microsoft kimlik platformu bir erişim belirtecinin güvenliğini sağlaması gerekir. Uygulama rollerini değil yalnızca temsilci kapsamları kullanır. Roller sorumluya (kullanıcı) bağlı kalır ve hiçbir zaman kullanıcı adına çalışan uygulamaya eklenmez. Bu, kullanıcının erişmemesi gereken kaynaklara izin almasını önlemek için oluşur.

Bu makalede uygulamanızda doğrudan protokol için programlama işlemi açıklanır. Mümkün olduğunda, belirteçleri almak ve güvenli web API’lerini aramak yerine desteklenen Microsoft Kimlik Doğrulama Kitaplıklarını (MSAL) kullanmanızı öneririz. Örnekler için MSAL kullanan örnek uygulamalara da bakın.

İstemci sınırlamaları

Hizmet sorumlusu yalnızca uygulama belirteci istediyse ve bunu bir API'ye gönderdiyse, bu API özgün hizmet sorumlusunu temsil etmeyen bir belirteç değişimi yapar. Bunun nedeni OBO akışının yalnızca kullanıcı sorumluları için çalışmasıdır. Bunun yerine, yalnızca uygulama belirteci almak için istemci kimlik bilgileri akışını kullanması gerekir. Tek sayfalı uygulamalar (SPA' lar) söz konusu olduğunda, bunun yerine OBO akışlarını gerçekleştirmek için bir erişim belirtecini orta katman gizli istemcisine geçirmeleri gerekir.

İstemci, id_token almak için örtük akışı kullanıyorsa ve yanıt URL'sinde joker karakterler varsa, id_token OBO akışı için kullanılamaz. Joker karakter, karakterle biten bir * URL'dir. Örneğin, yanıt URL'si ise https://myapp.com/* istemciyi tanımlayacak kadar özel olmadığından id_token kullanılamaz. Bu, belirtecin verilmesini engeller. Ancak, örtük verme akışı aracılığıyla alınan erişim belirteçleri, başlatan istemcinin joker karakter yanıt URL'si kayıtlı olsa bile gizli bir istemci tarafından kullanılır. Bunun nedeni gizli istemcinin erişim belirtecini alan istemciyi tanımlayabilmesidir. Gizli istemci daha sonra erişim belirtecini kullanarak aşağı akış API'sine yönelik yeni bir erişim belirteci alabilir.

Ayrıca, özel imzalama anahtarları olan uygulamalar OBO akışında orta katman API'leri olarak kullanılamaz. Bu, çoklu oturum açma için yapılandırılmış kurumsal uygulamaları içerir. Orta katman API'sinde özel imzalama anahtarı kullanılıyorsa, aşağı akış API'si ona geçirilen erişim belirtecinin imzasını doğrulamaz. İstemci tarafından denetlenen bir anahtarla imzalanan belirteçler güvenli bir şekilde kabul edilemediğinden bu hatayla sonuçlanır.

Protokol diyagramı

Kullanıcının OAuth 2.0 yetkilendirme kodu verme akışını veya başka bir oturum açma akışını kullanarak bir uygulamanın kimliğini doğruladığını varsayalım. Bu noktada uygulama, kullanıcının talepleri ve orta katman web API'sine (API A) erişme onayıyla API A (belirteç A) için bir erişim belirtecine sahiptir. Şimdi API A'nın aşağı akış web API'sine (API B) kimliği doğrulanmış bir istekte bulunması gerekiyor.

İzleyen adımlar OBO akışını oluşturur ve aşağıdaki diyagram yardımıyla açıklanır.

OAuth2.0 Adına akışını gösterir

İstemci uygulaması, A belirteci ile (API A talebiyle aud ) A API'sine bir istekte bulunur.
API A, Microsoft kimlik platformu belirteci verme uç noktasında kimlik doğrulaması yapar ve API B'ye erişmek için bir belirteç istemektedir.
Microsoft kimlik platformu belirteci verme uç noktası, A belirteci ile birlikte API A'nın kimlik bilgilerini doğrular ve API B (belirteç B) için erişim belirtecini API A'ya iletir.
B belirteci, API B'ye yapılan isteğin yetkilendirme üst bilgisinde API A tarafından ayarlanır.
Güvenli kaynaktan alınan veriler API B tarafından API A'ya ve ardından istemciye döndürülür.

Bu senaryoda, orta katman hizmetinin aşağı akış API'sine erişmek için kullanıcının onayını almak için kullanıcı etkileşimi yoktur. Bu nedenle, aşağı akış API'sine erişim verme seçeneği, kimlik doğrulaması sırasında onay adımının bir parçası olarak önceden sunulur. Bunu uygulamanızda nasıl uygulayacağınızı öğrenmek için bkz . Orta katman uygulaması için onay alma.

Orta katman erişim belirteci isteği

Erişim belirteci istemek için kiracıya özgü Microsoft kimlik platformu belirteci uç noktasına aşağıdaki parametrelerle bir HTTP POST oluşturun.

https://login.microsoftonline.com/<tenant>/oauth2/v2.0/token

Uyarı

Orta katmana verilen erişim belirteçlerini belirteç için hedeflenen hedef kitle dışında herhangi bir yere GÖNDERMEYİN . Orta katmana verilen erişim belirteçleri, hedeflenen hedef kitle uç noktasıyla iletişim kurmak için yalnızca bu orta katman tarafından kullanılmak üzere tasarlanmıştır.

Erişim belirteçlerini orta katmandaki bir kaynaktan istemciye geçirmenin güvenlik riskleri (erişim belirteçlerini istemcinin kendisi almak yerine) şunlardır:

Güvenliği aşılmış SSL/TLS kanalları üzerinde daha fazla belirteç kesme riski.
Belirteç bağlamasını ve talep adımlarını gerektiren Koşullu Erişim senaryolarını karşılayamama (örneğin, MFA, Oturum Açma Sıklığı).
Yönetici tarafından yapılandırılan cihaz tabanlı ilkelerle uyumsuzluk (örneğin, MDM, konum tabanlı ilkeler).

İstemci uygulamasının paylaşılan gizli diziyle mi yoksa sertifikayla mı güvenli hale getirileceğini seçmesine bağlı olarak iki durum vardır.

İlk durum: Paylaşılan gizli diziyle belirteç isteğine erişme

Paylaşılan gizli dizi kullanılırken, hizmet-hizmet erişim belirteci isteği aşağıdaki parametreleri içerir:

Parametre	Tür	Açıklama
`grant_type`	Gerekli	Belirteç isteğinin türü. JWT kullanan bir istek için değeri olmalıdır `urn:ietf:params:oauth:grant-type:jwt-bearer`.
`client_id`	Zorunlu	Microsoft Entra yönetim merkezi - Uygulama kayıtları sayfasının uygulamanıza atandığı uygulama (istemci) kimliği.
`client_secret`	Zorunlu	Microsoft Entra yönetim merkezi - Uygulama kayıtları sayfasında uygulamanız için oluşturduğunuz istemci gizli dizisi. Rfc 6749 başına Yetkilendirme üst bilgisinde kimlik bilgileri sağlamak yerine temel kimlik doğrulama deseni de desteklenir.
`assertion`	Zorunlu	Orta katman API'sine gönderilen erişim belirteci. Bu belirtecin, bu OBO isteğini yapan uygulamanın (alan tarafından `client-id` belirtilen uygulama) hedef kitlesine (`aud`) sahip olması gerekir. Uygulamalar farklı bir uygulama için belirteci kullanamaz (örneğin, bir istemci Microsoft Graph'a yönelik bir API gönderirse, API bunu OBO kullanarak kullanamaz. Bunun yerine belirteci reddetmelidir).
`scope`	Zorunlu	Belirteç isteği için boşlukla ayrılmış kapsam listesi. Daha fazla bilgi için bkz . kapsamlar.
`requested_token_use`	Zorunlu	İsteğin nasıl işlenmesi gerektiğini belirtir. OBO akışında değeri olarak `on_behalf_of`ayarlanmalıdır.

Örnek

Aşağıdaki HTTP POST, web API'sinin kapsamına https://graph.microsoft.com sahip user.read bir erişim belirteci ve yenileme belirteci istemektedir. İstek, gizli diziyle imzalanır ve gizli bir istemci tarafından yapılır.

//line breaks for legibility only
    
POST /oauth2/v2.0/token HTTP/1.1
Host: login.microsoftonline.com/<tenant>
Content-Type: application/x-www-form-urlencoded
    
grant_type=urn:ietf:params:oauth:grant-type:jwt-bearer
&client_id=00001111-aaaa-2222-bbbb-3333cccc4444
&client_secret=sampleCredentia1s
&assertion=eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsImtpZCI6InowMzl6ZHNGdWl6cEJmQlZLMVRuMjVRSFlPMCJ9.eyJhdWQiOiIyO{a lot of characters here}
&scope=https://graph.microsoft.com/user.read+offline_access
&requested_token_use=on_behalf_of

İkinci durum: Sertifika ile erişim belirteci isteği

Bir sertifikaya sahip hizmetten hizmete erişim belirteci isteği, önceki örnekteki parametrelere ek olarak aşağıdaki parametreleri içerir:

Parametre	Tür	Açıklama
`grant_type`	Gerekli	Belirteç isteğinin türü. JWT kullanan bir istek için değeri olmalıdır `urn:ietf:params:oauth:grant-type:jwt-bearer`.
`client_id`	Zorunlu	Microsoft Entra yönetim merkezi - Uygulama kayıtları sayfasının uygulamanıza atandığı uygulama (istemci) kimliği.
`client_assertion_type`	Zorunlu	Değer olmalıdır `urn:ietf:params:oauth:client-assertion-type:jwt-bearer`.
`client_assertion`	Zorunlu	Uygulamanız için kimlik bilgileri olarak kaydettiğiniz sertifikayı oluşturmanız ve bu sertifikayla imzalamanız gereken bir onay (JSON web belirteci). Sertifikanızı kaydetmeyi ve onaylama biçimini öğrenmek için bkz . sertifika kimlik bilgileri.
`assertion`	Zorunlu	Orta katman API'sine gönderilen erişim belirteci. Bu belirtecin, bu OBO isteğini yapan uygulamanın (alan tarafından `client-id` belirtilen uygulama) hedef kitlesine (`aud`) sahip olması gerekir. Uygulamalar farklı bir uygulama için belirteci kullanamaz (örneğin, bir istemci BIR API'ye MS Graph'e yönelik bir belirteç gönderirse, API bunu OBO kullanarak kullanamaz. Bunun yerine belirteci reddetmelidir).
`requested_token_use`	Zorunlu	İsteğin nasıl işlenmesi gerektiğini belirtir. OBO akışında değeri olarak `on_behalf_of`ayarlanmalıdır.
`scope`	Zorunlu	Belirteç isteği için boşlukla ayrılmış kapsam listesi. Daha fazla bilgi için bkz . kapsamlar.

Parametrelerin paylaşılan gizli dizi tarafından istek durumundakiyle hemen hemen aynı olduğuna dikkat edin, ancak parametresi iki client_secret parametreyle değiştirilir: a client_assertion_type ve client_assertion. client_assertion_type parametresi olarak urn:ietf:params:oauth:client-assertion-type:jwt-bearerclient_assertion, parametresi ise sertifikanın özel anahtarıyla imzalanan JWT belirtecine ayarlanır.

Örnek

Aşağıdaki HTTP POST, bir sertifikaya sahip user.read web API'sinin kapsamına https://graph.microsoft.com sahip bir erişim belirteci istemektedir. İstek, gizli diziyle imzalanır ve gizli bir istemci tarafından yapılır.

// line breaks for legibility only
    
POST /oauth2/v2.0/token HTTP/1.1
Host: login.microsoftonline.com/<tenant>
Content-Type: application/x-www-form-urlencoded
    
grant_type=urn%3Aietf%3Aparams%3Aoauth%3Agrant-type%3Ajwt-bearer
&client_id=11112222-bbbb-3333-cccc-4444dddd5555
&client_assertion_type=urn%3Aietf%3Aparams%3Aoauth%3Aclient-assertion-type%3Ajwt-bearer
&client_assertion=eyJhbGciOiJSUzI1NiIsIng1dCI6Imd4OHRHeXN5amNScUtqRlBuZDdSRnd2d1pJMCJ9.eyJ{a lot of characters here}
&assertion=eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6InowMzl6ZHNGdWl6cEJmQlZLMVRuMjVRSFlPMCIsImtpZCI6InowMzl6ZHNGdWl6cEJmQlZLMVRuMjVRSFlPMCJ9.eyJhdWQiO{a lot of characters here}
&requested_token_use=on_behalf_of
&scope=https://graph.microsoft.com/user.read+offline_access

Orta katman erişim belirteci yanıtı

Başarılı yanıt, aşağıdaki parametrelere sahip bir JSON OAuth 2.0 yanıtıdır.

Parametre	Açıklama
`token_type`	Belirteç türü değerini gösterir. Microsoft kimlik platformu tarafından desteklenen tek türdür`Bearer`. Taşıyıcı belirteçler hakkında daha fazla bilgi için bkz . OAuth 2.0 Yetkilendirme Çerçevesi: Taşıyıcı Belirteç Kullanımı (RFC 6750).
`scope`	Belirteçte verilen erişim kapsamı.
`expires_in`	Erişim belirtecinin geçerli olduğu süre (saniye cinsinden).
`access_token`	İstenen erişim belirteci. Çağıran hizmet, alıcı hizmette kimlik doğrulaması yapmak için bu belirteci kullanabilir.
`refresh_token`	İstenen erişim belirtecinin yenileme belirteci. Çağıran hizmet, geçerli erişim belirtecinin süresi dolduktan sonra başka bir erişim belirteci istemek için bu belirteci kullanabilir. Yenileme belirteci yalnızca kapsam istendiyse `offline_access` sağlanır.

Başarı yanıtı örneği

Aşağıdaki örnekte, web API'sine yönelik erişim belirteci isteğine verilen başarı yanıtı gösterilmektedir https://graph.microsoft.com . Yanıt bir erişim belirteci ve yenileme belirteci içerir ve sertifikanın özel anahtarıyla imzalanır.

{
    "token_type": "Bearer",
    "scope": "https://graph.microsoft.com/user.read",
    "expires_in": 3269,
    "ext_expires_in": 0,
    "access_token": "eyJ0eXAiOiJKV1QiLCJub25jZSI6IkFRQUJBQUFBQUFCbmZpRy1tQTZOVGFlN0NkV1c3UWZkQ0NDYy0tY0hGa18wZE50MVEtc2loVzRMd2RwQVZISGpnTVdQZ0tQeVJIaGlDbUN2NkdyMEpmYmRfY1RmMUFxU21TcFJkVXVydVJqX3Nqd0JoN211eHlBQSIsImFsZyI6IlJTMjU2IiwieDV0IjoiejAzOXpkc0Z1aXpwQmZCVksxVG4yNVFIWU8wIiwia2lkIjoiejAzOXpkc0Z1aXpwQmZCVksxVG4yNVFIWU8wIn0.eyJhdWQiOiJodHRwczovL2dyYXBoLm1pY3Jvc29mdC5jb20iLCJpc3MiOiJodHRwczovL3N0cy53aW5kb3dzLm5ldC83MmY5ODhiZi04NmYxLTQxYWYtOTFhYi0yZDdjZDAxMWRiNDcvIiwiaWF0IjoxNDkzOTMwMzA1LCJuYmYiOjE0OTM5MzAzMDUsImV4cCI6MTQ5MzkzMzg3NSwiYWNyIjoiMCIsImFpbyI6IkFTUUEyLzhEQUFBQU9KYnFFWlRNTnEyZFcxYXpKN1RZMDlYeDdOT29EMkJEUlRWMXJ3b2ZRc1k9IiwiYW1yIjpbInB3ZCJdLCJhcHBfZGlzcGxheW5hbWUiOiJUb2RvRG90bmV0T2JvIiwiYXBwaWQiOiIyODQ2ZjcxYi1hN2E0LTQ5ODctYmFiMy03NjAwMzViMmYzODkiLCJhcHBpZGFjciI6IjEiLCJmYW1pbHlfbmFtZSI6IkNhbnVtYWxsYSIsImdpdmVuX25hbWUiOiJOYXZ5YSIsImlwYWRkciI6IjE2Ny4yMjAuMC4xOTkiLCJuYW1lIjoiTmF2eWEgQ2FudW1hbGxhIiwib2lkIjoiZDVlOTc5YzctM2QyZC00MmFmLThmMzAtNzI3ZGQ0YzJkMzgzIiwib25wcmVtX3NpZCI6IlMtMS01LTIxLTIxMjc1MjExODQtMTYwNDAxMjkyMC0xODg3OTI3NTI3LTI2MTE4NDg0IiwicGxhdGYiOiIxNCIsInB1aWQiOiIxMDAzM0ZGRkEwNkQxN0M5Iiwic2NwIjoiVXNlci5SZWFkIiwic3ViIjoibWtMMHBiLXlpMXQ1ckRGd2JTZ1JvTWxrZE52b3UzSjNWNm84UFE3alVCRSIsInRpZCI6IjcyZjk4OGJmLTg2ZjEtNDFhZi05MWFiLTJkN2NkMDExZGI0NyIsInVuaXF1ZV9uYW1lIjoibmFjYW51bWFAbWljcm9zb2Z0LmNvbSIsInVwbiI6Im5hY2FudW1hQG1pY3Jvc29mdC5jb20iLCJ1dGkiOiJWR1ItdmtEZlBFQ2M1dWFDaENRSkFBIiwidmVyIjoiMS4wIn0.cubh1L2VtruiiwF8ut1m9uNBmnUJeYx4x0G30F7CqSpzHj1Sv5DCgNZXyUz3pEiz77G8IfOF0_U5A_02k-xzwdYvtJUYGH3bFISzdqymiEGmdfCIRKl9KMeoo2llGv0ScCniIhr2U1yxTIkIpp092xcdaDt-2_2q_ql1Ha_HtjvTV1f9XR3t7_Id9bR5BqwVX5zPO7JMYDVhUZRx08eqZcC-F3wi0xd_5ND_mavMuxe2wrpF-EZviO3yg0QVRr59tE3AoWl8lSGpVc97vvRCnp4WVRk26jJhYXFPsdk4yWqOKZqzr3IFGyD08WizD_vPSrXcCPbZP3XWaoTUKZSNJg",
    "refresh_token": "OAQABAAAAAABnfiG-mA6NTae7CdWW7QfdAALzDWjw6qSn4GUDfxWzJDZ6lk9qRw4An{a lot of characters here}"
}

Bu erişim belirteci, Microsoft Graph için v1.0 biçimli bir belirteçtir. Bunun nedeni, belirteç biçiminin erişilen kaynağa dayalı olması ve istekte bulunmak için kullanılan uç noktalarla ilgisiz olmasıdır. Microsoft Graph, v1.0 belirteçlerini kabul etmek üzere ayarlanır, bu nedenle bir istemci Microsoft Graph için belirteç istediğinde Microsoft kimlik platformu v1.0 erişim belirteçleri üretir. Diğer uygulamalar v2.0 biçimli belirteçler, v1.0 biçimli belirteçler, hatta özel veya şifrelenmiş belirteç biçimleri istediklerini gösterebilir. Hem v1.0 hem de v2.0 uç noktaları iki belirteç biçimini de yayar. Bu şekilde, istemci tarafından belirtecin nasıl veya nerede istendiğine bakılmaksızın kaynak her zaman doğru belirteç biçimini alabilir.

Uyarı

Bu örnekteki belirteçler de dahil olmak üzere sahip olmadığınız API'lerin belirteçlerini kodunuzda doğrulamayı veya okumayı denemeyin. Microsoft hizmetleri belirteçleri JWT olarak doğrulanmayacak özel bir biçim kullanabilir ve tüketici (Microsoft hesabı) kullanıcıları için de şifrelenebilir. Belirteçleri okumak yararlı bir hata ayıklama ve öğrenme aracı olsa da, kodunuzda buna bağımlılıkları almayın veya denetlediğiniz bir API için olmayan belirteçlerle ilgili belirli bilgileri varsaymayın.

Hata yanıtı örneği

Aşağı akış API'sinde Koşullu Erişim ilkesi (çok faktörlü kimlik doğrulaması gibi) kümesi varsa, aşağı akış API'sinin erişim belirteci alınmaya çalışılırken belirteç uç noktası tarafından bir hata yanıtı döndürülür. Orta katman hizmeti, istemci uygulamasının Koşullu Erişim ilkesini karşılamak için kullanıcı etkileşimi sağlayabilmesi için bu hatayı istemci uygulamasına sunmalıdır.

Bu hatayı istemciye geri döndürmek için, orta katman hizmeti HTTP 401 Yetkisiz ve hatayı ve talep sınamasını içeren bir WWW-Authenticate HTTP üst bilgisi ile yanıtlar. İstemci, varsa talep sınamasını sunarak bu üst bilgiyi ayrıştırmalı ve belirteç verenden yeni bir belirteç almalıdır. İstemciler, önbelleğe alınmış erişim belirteci kullanarak orta katman hizmetine erişmeyi yeniden denememelidir.

{
    "error":"interaction_required",
    "error_description":"AADSTS50079: Due to a configuration change made by your administrator, or because you moved to a new location, you must enroll in multifactor authentication to access 'aaaaaaaa-0000-1111-2222-bbbbbbbbbbbb'.\r\nTrace ID: 0000aaaa-11bb-cccc-dd22-eeeeee333333\r\nCorrelation ID: aaaa0000-bb11-2222-33cc-444444dddddd\r\nTimestamp: 2017-05-01 22:43:20Z",
    "error_codes":[50079],
    "timestamp":"2017-05-01 22:43:20Z",
    "trace_id":"0000aaaa-11bb-cccc-dd22-eeeeee333333",
    "correlation_id":"aaaa0000-bb11-2222-33cc-444444dddddd",
    "claims":"{\"access_token\":{\"polids\":{\"essential\":true,\"values\":[\"00aa00aa-bb11-cc22-dd33-44ee44ee44ee\"]}}}"
}

Güvenli kaynağa erişmek için erişim belirtecini kullanma

Artık orta katman hizmeti, üst bilgideki belirteci ayarlayarak aşağı akış web API'sine kimliği doğrulanmış istekler yapmak için daha önce alınan belirteci Authorization kullanabilir.

Örnek

    GET /v1.0/me HTTP/1.1
    Host: graph.microsoft.com
    Authorization: Bearer eyJ0eXAiO ... 0X2tnSQLEANnSPHY0gKcgw

OAuth2.0 OBO akışıyla alınan SAML onayları

Bazı OAuth tabanlı web hizmetlerinin etkileşimli olmayan akışlarda SAML onaylarını kabul eden diğer web hizmeti API'lerine erişmesi gerekir. Microsoft Entra Id, hedef kaynak olarak SAML tabanlı bir web hizmeti kullanan Bir Adına Akışına yanıt olarak bir SAML onaylaması sağlayabilir.

Bu, OAuth2 tabanlı bir uygulamanın SAML belirteçleri kullanan web hizmeti API'si uç noktalarına erişmesine olanak tanıyan OAuth 2.0 On-Behalf-Of akışının standart olmayan bir uzantısıdır.

İpucu

Bir ön uç web uygulamasından SAML korumalı bir web hizmetini çağırdığınızda, API'yi çağırabilir ve kullanıcının mevcut oturumuyla normal bir etkileşimli kimlik doğrulama akışı başlatabilirsiniz. Yalnızca hizmet-hizmet çağrısı kullanıcı bağlamı sağlamak için SAML belirteci gerektirdiğinde OBO akışı kullanmanız gerekir.

Paylaşılan gizli dizi ile OBO isteği kullanarak SAML belirteci alma

SAML onayı için hizmet-hizmet isteği aşağıdaki parametreleri içerir:

Parametre	Tür	Açıklama
grant_type	gerekli	Belirteç isteğinin türü. JWT kullanan bir istek için değeri olmalıdır `urn:ietf:params:oauth:grant-type:jwt-bearer`.
assertion	gerekli	İstekte kullanılan erişim belirtecinin değeri.
client_id	gerekli	Microsoft Entra Id ile kayıt sırasında çağrı hizmetine atanan uygulama kimliği. Microsoft Entra yönetim merkezinde uygulama kimliğini bulmak için Kimlik>Uygulamaları'na> göz atın Uygulama kayıtları ardından uygulama adını seçin.
client_secret	gerekli	Microsoft Entra Id'de çağrı hizmeti için kaydedilen anahtar. Bu değer kayıt sırasında not edilmelidir. Rfc 6749 başına Yetkilendirme üst bilgisinde kimlik bilgileri sağlamak yerine temel kimlik doğrulama deseni de desteklenir.
kapsam	gerekli	Belirteç isteği için boşlukla ayrılmış kapsam listesi. Daha fazla bilgi için bkz . kapsamlar. SAML'nin kendisinde kapsam kavramı yoktur, ancak belirteci almak istediğiniz hedef SAML uygulamasını tanımlamak için kullanılır. Bu OBO akışı için kapsam değeri her zaman eklenmiş SAML Varlık Kimliği `/.default` olmalıdır. Örneğin, SAML uygulamasının Varlık Kimliği olması `https://testapp.contoso.com`durumunda istenen kapsam olmalıdır `https://testapp.contoso.com/.default`. Varlık Kimliği gibi `https:`bir URI düzeniyle başlamıyorsa, Microsoft Entra Varlık Kimliği'ne ile `spn:`ön ek ekler. Bu durumda, örneğin Varlık Kimliğinin olması `testapp`durumunda kapsamını `spn:<EntityID>/.defaultspn:testapp/.default` istemeniz gerekir. Burada istediğiniz kapsam değeri SAML belirtecindeki sonuç `Audience` öğesini belirler. Bu, belirteci alan SAML uygulaması için önemli olabilir.
requested_token_use	gerekli	İsteğin nasıl işlenmesi gerektiğini belirtir. Adına Akışında değeri olmalıdır `on_behalf_of`.
requested_token_type	gerekli	İstenen belirteç türünü belirtir. Değer, erişilen kaynağın gereksinimlerine bağlı olarak veya `urn:ietf:params:oauth:token-type:saml1` olabilir`urn:ietf:params:oauth:token-type:saml2`.

Yanıt, UTF8 ve Base 64url'de kodlanmış bir SAML belirteci içerir.

OBO çağrısından kaynaklanan bir SAML onaylama işlemi için SubjectConfirmationData: Hedef uygulama içinde SubjectConfirmationDatabir Recipient değer gerektiriyorsa, değerin kaynak uygulaması yapılandırmasındaki ilk anahtarsız Yanıt URL'si olarak yapılandırılması gerekir. Değeri belirlemek Recipient için varsayılan Yanıt URL'si kullanılmadığından, ilk döndürülmeyen Yanıt URL'sinin kullanıldığından emin olmak için uygulama yapılandırmasındaki Yanıt URL'lerini yeniden sıralamanız gerekebilir. Daha fazla bilgi için bkz . Yanıt URL'leri.
SubjectConfirmationData düğümü: SamL yanıtının parçası InResponseTo olmadığından düğüm öznitelik içeremez. SAML belirtecini alan uygulamanın bir InResponseTo öznitelik olmadan SAML onayını kabul edebilmesi gerekir.
API izinleri: SAML uygulamasına erişime izin vermek için, SAML uygulamasının kapsamı için belirteç isteyebilmesi için orta katman uygulamasına /.default gerekli API izinlerini eklemeniz gerekir.
Onay: OAuth akışında kullanıcı verilerini içeren bir SAML belirteci almak için onay verilmelidir. Bilgi için bkz . Orta katman uygulaması için onay alma.

SAML onay ile yanıt

Parametre	Açıklama
token_type	Belirteç türü değerini gösterir. Microsoft Entra ID'nin desteklediği tek tür Taşıyıcı'dır. Taşıyıcı belirteçler hakkında daha fazla bilgi için bkz . OAuth 2.0 Yetkilendirme Çerçevesi: Taşıyıcı Belirteç Kullanımı (RFC 6750).
kapsam	Belirteçte verilen erişim kapsamı.
expires_in	Erişim belirtecinin geçerli olduğu süre (saniye cinsinden).
expires_on	Erişim belirtecinin süresinin dolma zamanı. Tarih, son kullanma tarihine kadar 1970-01-01T0:0:0Z UTC arasındaki saniye sayısı olarak gösterilir. Bu değer, önbelleğe alınan belirteçlerin ömrünü belirlemek için kullanılır.
kaynak	Alıcı hizmetin uygulama kimliği URI'si (güvenli kaynak).
access_token	SAML onayını döndüren parametre.
refresh_token	Yenileme belirteci. Çağıran hizmet, geçerli SAML onay süresi dolduktan sonra başka bir erişim belirteci istemek için bu belirteci kullanabilir.

token_type: Taşıyıcı
expires_in: 3296
ext_expires_in: 0
expires_on: 1529627844
Kaynak: https://api.contoso.com
access_token: <SAML onayı>
issued_token_type: urn:ietf:params:oauth:token-type:saml2
refresh_token: <Belirteci yenileme>

OBO akışının amacı, istemci uygulamasının orta katman uygulamasını çağırabilmesi ve orta katman uygulamasının arka uç kaynağını çağırma iznine sahip olması için uygun onayın verildiğinden emin olmaktır. Uygulamanızın mimarisine veya kullanımına bağlı olarak, OBO akışının başarılı olduğundan emin olmak için aşağıdakileri göz önünde bulundurmanız gerekir:

Orta katman uygulaması, istemciyi bildirimindeki bilinen istemci uygulamaları listesine (knownClientApplications) ekler. İstemci tarafından bir onay istemi tetikleniyorsa, onay akışı hem kendisi hem de orta katman uygulaması içindir. Microsoft kimlik platformu, bu kapsam kullanılarak .default yapılır. Kapsam .default , uygulamanın izinlerine sahip olduğu tüm kapsamlara erişim izni istemek için kullanılan özel bir kapsamdır. Bu, uygulamanın birden çok kaynağa erişmesi gerektiğinde yararlıdır, ancak kullanıcıdan yalnızca bir kez onay istenmesi gerekir.

bilinen istemci uygulamalarını ve .defaultkullanarak bir onay ekranı tetiklerken, onay ekranı hem istemcinin orta katman API'sine yönelik izinleri gösterir hem de orta katman API'sinin gerektirdiği izinleri isteyebilir. Kullanıcı her iki uygulama için de onay sağlar ve ardından OBO akışı çalışır.

İstekte tanımlanan kaynak hizmeti (API), kullanıcının oturum açma işlemi sonucunda istemci uygulamasının erişim belirteci istediği API olmalıdır. Örneğin, scope=openid https://middle-tier-api.example.com/.default (orta katman API'sine erişim belirteci istemek için) veya scope=openid offline_access .default (bir kaynak tanımlanmadığında varsayılan olarak Microsoft Graph olur).

Yetkilendirme isteğinde hangi API'nin tanımlandığına bakılmaksızın, onay istemi istemci uygulaması için yapılandırılan tüm gerekli izinlerle birleştirilir. İstemciyi bilinen bir istemci uygulaması olarak tanımlayan istemcinin gerekli izinler listesinde listelenen her orta katman API'sine yönelik olarak yapılandırılan tüm gerekli izinler de eklenir.

Önceden yetkilendirilmiş uygulamalar

Kaynaklar, belirli bir uygulamanın her zaman belirli kapsamları alma iznine sahip olduğunu gösterebilir. Bu, ön uç istemcisiyle arka uç kaynağı arasındaki bağlantıları daha sorunsuz hale getirmek için kullanışlıdır. Bir kaynak, bildiriminde birden çok önceden doğrulanmış uygulama (preAuthorizedApplications) bildirebilir. Bu tür uygulamalar bir OBO akışında bu izinleri isteyebilir ve kullanıcı onay vermeden alabilir.

Kiracı yöneticisi, orta katman uygulaması için yönetici onayı sağlayarak uygulamaların gerekli API'lerini çağırma iznine sahip olduğunu garanti edebilir. Bunu yapmak için yönetici, orta katman uygulamasını kiracısında bulabilir, gerekli izinler sayfasını açabilir ve uygulama için izin vermeyi seçebilir. Yönetici onayı hakkında daha fazla bilgi edinmek için onay ve izin belgelerine bakın.

Tek bir uygulamanın kullanımı

Bazı senaryolarda yalnızca orta katman ve ön uç istemci çifti olabilir. Bu senaryoda, orta katman uygulama gereksinimini tamamen ortadan kaldırarak bunu tek bir uygulama haline getirmenin daha kolay olduğunu fark edebilirsiniz. Ön uç ile web API'si arasında kimlik doğrulaması yapmak için tanımlama bilgilerini, id_token veya uygulamanın kendisi için istenen erişim belirtecini kullanabilirsiniz. Ardından, bu tek uygulamadan arka uç kaynağına onay isteyin.

Ayrıca bkz.

OAuth 2.0 protokolü ve istemci kimlik bilgilerini kullanarak hizmet kimlik doğrulaması gerçekleştirmenin başka bir yolu hakkında daha fazla bilgi edinin.

Aracılığıyla paylaş

Microsoft kimlik platformu ve OAuth 2.0 Adına akışı

İstemci sınırlamaları

Protokol diyagramı

Orta katman erişim belirteci isteği

İlk durum: Paylaşılan gizli diziyle belirteç isteğine erişme

Örnek

İkinci durum: Sertifika ile erişim belirteci isteği

Örnek

Orta katman erişim belirteci yanıtı

Başarı yanıtı örneği

Hata yanıtı örneği

Güvenli kaynağa erişmek için erişim belirtecini kullanma

Örnek

OAuth2.0 OBO akışıyla alınan SAML onayları

Paylaşılan gizli dizi ile OBO isteği kullanarak SAML belirteci alma

SAML onay ile yanıt

Önceden yetkilendirilmiş uygulamalar

Tek bir uygulamanın kullanımı

Ayrıca bkz.

Geri Bildirim

Ek kaynaklar

Aracılığıyla paylaş

Microsoft kimlik platformu ve OAuth 2.0 Adına akışı

İstemci sınırlamaları

Protokol diyagramı

Orta katman erişim belirteci isteği

İlk durum: Paylaşılan gizli diziyle belirteç isteğine erişme

Örnek

İkinci durum: Sertifika ile erişim belirteci isteği

Örnek

Orta katman erişim belirteci yanıtı

Başarı yanıtı örneği

Hata yanıtı örneği

Güvenli kaynağa erişmek için erişim belirtecini kullanma

Örnek

OAuth2.0 OBO akışıyla alınan SAML onayları

Paylaşılan gizli dizi ile OBO isteği kullanarak SAML belirteci alma

SAML onay ile yanıt

Orta katman uygulaması için onay alma

.default ve birleşik onay

Önceden yetkilendirilmiş uygulamalar

Yönetici onayı

Tek bir uygulamanın kullanımı

Ayrıca bkz.

Geri Bildirim

Ek kaynaklar