Microsoft kimlik platformu ve OAuth 2.0 Adına akışı
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.
- İ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_ofayarlanmalı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_ofayarlanmalı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ürBearer. 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\":[\"9ab03e19-ed42-4168-b6b7-7001fb3e933a\"]}}}"
}
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.comdurumunda 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ı testappdurumunda 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 olabilirurn: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
SubjectConfirmationDatabirRecipientdeğ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 belirlemekRecipientiç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ı
InResponseToolmadığından düğüm öznitelik içeremez. SAML belirtecini alan uygulamanın birInResponseToö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
/.defaultgerekli 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>
Orta katman uygulaması için onay alma
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:
.default ve birleşik onay
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.
Yönetici onayı
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.