Azure DevOps OAuth 2.0 gebruiken

Azure DevOps Services

In dit artikel wordt uitgelegd hoe Azure DevOps OAuth 2.0 werkt voor bestaande toepassingen en biedt richtlijnen voor het onderhouden en migreren van uw apps.

Overzicht

Met Azure DevOps OAuth 2.0 hebben toepassingen namens gebruikers toegang tot Azure DevOps-resources. Hoewel deze service is afgeschaft, blijven bestaande toepassingen functioneren tot 2026.

Aanbeveling voor migratie: begin met het plannen van uw migratie naar Microsoft Entra ID OAuth om de continue service en toegang tot verbeterde beveiligingsfuncties te garanderen.

Vereiste voorwaarden

Voordat u met Azure DevOps OAuth-toepassingen werkt:

Werken met bestaande Azure DevOps OAuth-apps

1. Uw bestaande app-registratie beheren

Voor bestaande toepassingen kunt u uw app-instellingen bekijken en beheren:

1. Ga naar uw Visual Studio-profiel voor toegang tot uw app-registraties.

2. Controleer de geconfigureerde bereiken en zorg ervoor dat deze overeenkomen met de behoeften van uw toepassing.

3. Controleer de configuratie van de callback-URL en werk indien nodig bij.

   

4. Plan uw migratietijdlijn naar Microsoft Entra ID OAuth vóór de deadline voor afschaffing van 2026.

2. Uw app autoriseren

De autorisatiestroom blijft hetzelfde voor bestaande Azure DevOps OAuth-apps:

1. Gebruikers doorsturen naar de autorisatie-URL met uw app-parameters:

   https://app.vssps.visualstudio.com/oauth2/authorize
           ?client_id={app ID}
           &response_type=Assertion
           &state={state}
           &scope={scope}
           &redirect_uri={callback URL}
   

   Kenmerk	Soort	Beschrijving
   client_id	GUID (Globaal Unieke Identificatie)	De id die aan uw app is toegewezen toen deze is geregistreerd
   response_type	tekenreeks	Moet Assertion zijn
   state	tekenreeks	Een gegenereerde tekenreekswaarde die de callback correleert met de autorisatieaanvraag
   scope	tekenreeks	Spatie-gescheiden scopes die zijn geregistreerd met de app. Beschikbare bereiken bekijken
   redirect_uri	URL	Callback-URL voor uw app. Moet exact overeenkomen met de URL die is geregistreerd bij de app

   Voorbeeld van autorisatie-URL:

   https://app.vssps.visualstudio.com/oauth2/authorize
           ?client_id=00001111-aaaa-2222-bbbb-3333cccc4444
           &response_type=Assertion
           &state=User1
           &scope=vso.work%20vso.code_write
           &redirect_uri=https://fabrikam.azurewebsites.net/myapp/oauth-callback
   

   Na gebruikersautorisatie wordt Azure DevOps omgeleid naar uw callback-URL met de autorisatiecode:

   https://fabrikam.azurewebsites.net/myapp/oauth-callback
           ?code={authorization code}
           &state=User1
   

3. Exchange-autorisatiecode voor toegangstoken

Gebruik de autorisatiecode om een toegangstoken en vernieuwingstoken aan te vragen:

Details van aanvraag

URL

POST https://app.vssps.visualstudio.com/oauth2/token

Kopteksten

Content-Type: application/x-www-form-urlencoded

aanvraaginhoud

client_assertion_type=urn:ietf:params:oauth:client-assertion-type:jwt-bearer&client_assertion={0}&grant_type=urn:ietf:params:oauth:grant-type:jwt-bearer&assertion={1}&redirect_uri={2}

Vervanging van parameters:

• {0}: URL-gecodeerde cliëntgeheim van de app-registratie
• {1}: door URL gecodeerde autorisatiecode van callback
• {2}: Callback-URL geregistreerd bij de app

Voorbeeld van C#-implementatie

public string GenerateRequestPostData(string appSecret, string authCode, string callbackUrl)
{
   return String.Format("client_assertion_type=urn:ietf:params:oauth:client-assertion-type:jwt-bearer&client_assertion={0}&grant_type=urn:ietf:params:oauth:grant-type:jwt-bearer&assertion={1}&redirect_uri={2}",
               HttpUtility.UrlEncode(appSecret),
               HttpUtility.UrlEncode(authCode),
               callbackUrl
        );
}

Reactie

{
    "access_token": "{ access token for the user }",
    "token_type": "{ type of token }",
    "expires_in": "{ time in seconds that the token remains valid }",
    "refresh_token": "{ refresh token to use to acquire a new access token }"
}

4. Het toegangstoken gebruiken

Neem het toegangstoken op als bearer-token in uw API-aanvragen:

Indeling van autorisatieheader:

Authorization: Bearer {access_token}

Voorbeeld van API-aanvraag:

GET https://dev.azure.com/myaccount/myproject/_apis/build-release/builds?api-version=3.0
Authorization: Bearer {access_token}

5. Verlopen toegangstokens vernieuwen

Wanneer toegangstokens verlopen, gebruikt u het vernieuwingstoken om een nieuw toegangstoken op te halen:

Verzoek:

POST https://app.vssps.visualstudio.com/oauth2/token
Content-Type: application/x-www-form-urlencoded
Content-Length: 1654

client_assertion_type=urn:ietf:params:oauth:client-assertion-type:jwt-bearer&client_assertion={0}&grant_type=refresh_token&assertion={1}&redirect_uri={2}

Vervanging van parameters:

• {0}: CLIENTgeheim met URL-codering
• {1}: URL-gecodeerde vernieuwingssleutel
• {2}: Callback-URL geregistreerd bij de app

Antwoord:

{
    "access_token": "{ new access token }",
    "token_type": "{ type of token }",
    "expires_in": "{ time in seconds that the token remains valid }",
    "refresh_token": "{ new refresh token }"
}

Codevoorbeelden

U vindt werkvoorbeelden in onze opslagplaats met Azure DevOps-verificatievoorbeelden.

App-geheimen beheren

Azure DevOps OAuth-apps ondersteunen dubbele geheimen om rotatie zonder downtime mogelijk te maken:

Geheimen bijwerken

1. Genereer een nieuw geheim in uw Visual Studio-profiel of via de API's voor het registratiegeheim.

   

2. Bevestig de actie in het modale dialoogvenster.

   

3. Werk uw toepassing bij om het nieuwe geheim te gebruiken voordat het oude is verlopen.

4. Test het nieuwe geheim grondig voordat het oude geheim verloopt.

5. Herhaal het proces wanneer het nieuwe geheim de vervaldatum nadert.

Intrekking van noodgeheim

Als een geheim is gecompromitteerd:

1. Genereer het geheim onmiddellijk opnieuw in uw profiel.
2. Werk uw toepassing bij met het nieuwe geheim.
3. Controleer op onbevoegde toegang in uw toepassingslogboeken.

De app verwijderen

Een Azure DevOps OAuth-app verwijderen:

1. Ga naar uw Visual Studio-profiel.

2. Selecteer de juiste tenant in de vervolgkeuzelijst.

3. Zoek uw app onder Toepassingen en services.

4. Selecteer Verwijderen op de registratiepagina van de toepassing.

   

5. Bevestig de verwijdering in het modale dialoogvenster.

Na verwijdering werken de app en alle bijbehorende tokens onmiddellijk niet meer.

Migratieplanning

Migratiecontrolelijst

• [] Raadpleeg de OAuth-documentatie voor Microsoft Entra ID
• [ ] Identificeer alle apps die Azure DevOps OAuth gebruiken in uw organisatie
• [] Planning van de migratietijdlijn voor voldoende testtijd
• [ ] Toepassingsarchitectuur bijwerken ter ondersteuning van Microsoft Entra ID OAuth
• [ ] Migratie testen in een niet-productieomgeving
• [ ] Wijzigingen aan gebruikers en belanghebbenden doorgeven
• [ ] Migratie voltooien vóór de deadline van 2026

Migratievoordelen

Verbeterde beveiligingsfuncties:

• Ondersteuning voor meervoudige verificatie
• Voorwaardelijke toegang beleidsregels
• Geavanceerde beveiliging tegen bedreigingen
• Bedrijfsidentiteitsintegratie

Betere ontwikkelaarservaring:

• Moderne verificatiebibliotheken (MSAL)
• Consistent identiteitsplatform in Microsoft-services
• Beter tokenbeheer en caching

Langetermijnondersteuning:

• Voortdurende investeringen en functieontwikkeling
• Bedrijfsnalevings- en governancefuncties

Veelgestelde vragen

V: Kan ik nog steeds nieuwe Azure DevOps OAuth-apps maken?

A: Nee. Nieuwe app-registraties zijn in april 2025 gestopt. Gebruik Microsoft Entra ID OAuth voor nieuwe toepassingen.

V: Wanneer werkt mijn bestaande Azure DevOps OAuth-app niet meer?

A: Bestaande apps blijven functioneren totdat Azure DevOps OAuth in 2026 volledig is afgeschaft. Plan uw migratie ruim vóór deze deadline.

V: Kan ik OAuth gebruiken met mobiele toepassingen?

A: Azure DevOps OAuth ondersteunt alleen de webserverstroom en vereist beveiligde opslag van clientgeheimen, waardoor deze niet geschikt is voor mobiele apps. Microsoft Entra ID OAuth biedt betere ondersteuning voor mobiele apps.

V: Wat moet ik doen als ik een HTTP 400-fout krijg bij het aanvragen van tokens?

A: Veelvoorkomende oorzaken zijn:

• Onjuiste Content-Type koptekst (moet zijn application/x-www-form-urlencoded)
• Onjuist gevormde aanvraaglichaamparameters
• Ongeldige of verlopen autorisatiecode
• Niet-overeenkomende callback-URL

V: Waarom krijg ik HTTP 401-fouten met OAuth-tokens, maar niet met PAT's?

A: Controleer of de beheerder van uw organisatie de toegang tot toepassingen van derden via OAuth heeft uitgeschakeld op: https://dev.azure.com/{your-org-name}/_settings/organizationPolicy

Wanneer deze functie is uitgeschakeld, werken OAuth-autorisatiestromen, maar worden API-aanroepen geretourneerd TF400813: The user "<GUID>" is not authorized to access this resource.

V: Kan ik localhost gebruiken om te testen?

A: Ja. Azure DevOps OAuth ondersteunt https://localhost callback-URL's voor lokale ontwikkeling en testen.

V: Hoe kan ik autorisatieweigeringen en intrekkingen afhandelen?

A: De juiste foutafhandeling implementeren voor:

• Autorisatieontkenning: er wordt geen autorisatiecode geretourneerd in de callback
• Ingetrokken autorisatie: API-aanroepen retourneren 401-fouten; autorisatie opnieuw aanvragen bij de gebruiker

V: Wat is het verschil tussen Azure DevOps OAuth en Microsoft Entra ID OAuth?

A:

• Azure DevOps OAuth: afgeschaft, Azure DevOps-specifieke, beperkte beveiligingsfuncties
• Microsoft Entra ID OAuth: Moderne, hoogwaardige, verbeterde beveiliging, langetermijnondersteuning

Volgende stappen

Voor bestaande toepassingen:

Voor nieuwe toepassingen:

Verwante inhoud

• Uw verificatiemethode kiezen
• Migreren naar Microsoft Entra ID OAuth
• OAuth 2.0-scopes beoordelen voor Azure DevOps
• App-autorisaties beheren
• Azure DevOps REST API-referentie verkennen
• Meer informatie over beveiliging en identiteit in Azure DevOps