Sökresultat :

×
Registrera Kontakta oss

OAuth API-dokumentation

Beviljande av auktoriseringskod

  • Behörighetsbegäran

    • Applikationen behöver först bestämma vilka behörigheter den begär och sedan skicka användaren till en webbläsare för att få deras behörighet. För att starta detta auktoriseringsflöde, skapa en URL enligt nedan och omdirigera slutanvändarens webbläsare till URL:en: 
      •             FÅ http://<wp_base_url>/wp-json/moserver/authorize
            ?response_type=code
            &client_id= <client_id_goes_here>
            &redirect_uri= <callback_url>
            &scope= <permissions_requesting>
            &state= <security_token>
    • response_type=kod : Den typ av svar du förväntar dig. För att få auktoriseringskoden måste den ha ett värde. kodaDetta talar om för auktoriseringsservern att programmet initierar auktoriseringsflödet.
    • Klient ID : Klient-ID som tillhandahålls av OAuth-leverantören.
    • redirect_uri : Återanrops-URL som användaren omdirigeras till när de tillåter eller nekar åtkomst till din app.
    • omfattning: En eller flera mellanslagsseparerade strängar som anger vilken behörighet din applikation begär.
    • stat : Applikationen genererar en slumpmässig sträng och inkluderar den i begäran. Den bör sedan kontrollera att samma värde returneras efter att användaren auktoriserat appen.
    • Om användaren tillåter åtkomst till din app kommer deras webbläsare att omdirigeras till den angivna omdirigerings-URL:en och begäran kommer att inkludera koda och tillstånd parametrar i frågesträngen.
    • Användaren kan till exempel omdirigeras tillbaka till URL som t.ex
      •               https://example-app.com/redirect
              ?code=<authorization-code>
              &state=<security_token>
    • Ocuco-landskapet koda är en auktoriseringskod som kan bytas mot en åtkomsttoken. Den genereras av auktoriseringsservern och är relativt kortlivad.
    • Ocuco-landskapet tillstånd är samma säkerhetstoken som applikationen ursprungligen angav i begäran.

  • Token-förfrågan

    • Om slutanvändaren har beviljat din app åtkomst och du får en auktoriseringskod kan du byta ut auktoriseringskoden mot en åtkomsttoken genom att göra en POST-begäran till token-slutpunkten.
    • Följande är ett exempel på POST-begäran:
      •               POST http://<wp_base_url>/wp-json/moserver/token
              Content-Type: application/x-www-form-urlencoded
         
              grant_type=authorization_code&
              code=<authorization_code>&
              client_id=<client_id>&
              client_secret=<clientSecret>&
              redirect_uri=<redirect_uri>
    • Här är beskrivningen för varje begäran parameter.
      • grant_type=auktorisationskod : Den typ av beviljande du tillhandahåller. Detta anger att applikationen använder auktoriseringskoden beviljandetypen.
      • kod: Auktoriseringskoden som mottogs i föregående steg, inkluderad här.
      • redirect_uri: Samma URI som angavs tidigare i auktoriseringsbegäran.
      • Klient ID : Klient-ID:t som tillhandahålls av OAuth-leverantören.
      • client_secret : Klienthemligheten som tillhandahålls av OAuth-leverantören.
    • Vid token-slutpunkten verifieras alla parametrar i begäran, vilket säkerställer att koden inte har gått ut och att klient-ID och hemlighet matchar. Om begäran lyckas genereras en åtkomsttoken och returneras i svaret: 
      •               HTTP/1.1 200 OK Content-Type: application/json Cache-Control: no-store { "access_token":"hkjher92u9eu2u3uihi2eh9293", "token_type":"bärare", "expires_in":3600, "scope":"profile", "id_token":"" }
    • Här är beskrivningen för varje parameter som tas emot i svaret.
      • access_token : åtkomsttoken för Userinfo-slutpunkten.
      • token_type : OAuth 2.0-tokentypvärde. Värdet måste vara Bärare.
      • går ut om : Utgångstiden för åtkomsttoken.
      • omfattning: En eller flera mellanslagsseparerade strängar som anger vilken behörighet din applikation begär.
      • id_token: ID-token är en säkerhetstoken som innehåller anspråk om autentisering av en slutanvändare av en auktoriseringsserver när en klient används, och potentiellt andra begärda anspråk.
    • Om begäran misslyckas kommer svaret att ha statusen 404 dålig förfrågan och kommer att ha följande innehåll: 
      •               "error" : "invalid_request", "error_description" : "En mer detaljerad beskrivning av felet avsett för utvecklaren av din app."

  • Resursbegäran

    • Om tokenbegäran lyckas får du åtkomst_token i svaret som kan användas för att komma åt de skyddade resurserna via API:et.
    • Användarinfo begäran: Följande är ett icke-formativt exempel på en Userinfo-förfrågan: 
      •                    FÅ http://<wp_base_url>/wp-json/moserver/resource
                   Host: server.example.com
                   Authorization: Bearer <access_token>
    • Resursservern validerar och verifierar åtkomsttoken och kontrollerar om den inte har löpt ut. Om resursbegäran är giltig returnerar resursservern anspråken, vilka representeras av ett JSON-objekt som innehåller en samling namn- och värdepar för anspråken.
    • Lyckad användarinformationssvar:
    • UserInfo-kraven MÅSTE returneras som medlemmar i ett JSON-objekt.

      Nedan är exemplet: 
      •                 { "id": "1", "username": "abc", "first_name": "xyz", "last_name": "example", "picture": "https://example.com/-kwtzesU/photo .jpg", "email": "abc@example.com", "locale": "en",... }

Implicit Code Grant

  • Behörighetsbegäran

    • Applikationen behöver först bestämma vilka behörigheter den begär och sedan skicka användaren till en webbläsare för att få deras behörighet. För att starta detta implicita flöde, skapa en URL enligt nedan och omdirigera slutanvändarens webbläsare till URL:en: 
      •               Skaffa sig http://<wp_base_url>/wp-json/moserver/authorize 
              ?response_type=token
              &client_id= <client_id_goes_here>
              &redirect_uri= <callback_url>
              &scope= <permissions_requesting>
              &state= <security_token>
    • response_type=token : Den typ av svar du förväntar dig. Detta talar om för auktoriseringsservern att programmet initierar det implicitta flödet. Observera skillnaden från auktoriseringskodflödet där detta värde är inställt på kod.
    • Klient ID : Klient-ID som tillhandahålls av OAuth-leverantören.
    • redirect_uri : Återanrops-URL som användaren omdirigeras till när de tillåter eller nekar åtkomst till din app.
    • omfattning: En eller flera mellanslagsseparerade strängar som anger vilken behörighet din applikation begär.
    • stat : Applikationen genererar en slumpmässig sträng och inkluderar den i begäran. Den bör sedan kontrollera att samma värde returneras efter att användaren auktoriserat appen.
    • Om användaren tillåter åtkomst till din app kommer deras webbläsare att omdirigeras till den angivna omdirigerings-URL:en och begäran kommer att inkludera token och tillstånd parametrar i frågesträngen.
    • Användaren kan till exempel omdirigeras tillbaka till callback URL som t.ex 
      •         https://callback-url?
        #access_token=<access_token>
        &token_type=Bearer
        &expires_in=3600
        &scope=<permissions_requesting>
    • Observera de två stora skillnaderna mellan detta och auktoriseringskodflödet: åtkomsttoken returneras istället för auktoriseringskoden i svaret.
    • Klienten kan sedan använda åtkomst_token för att komma åt skyddade resurser från resursservern.
      Här är beskrivningen för varje parameter som tas emot i svaret.
      • access_token : åtkomsttoken för Userinfo-slutpunkten.
      • token_type : OAuth 2.0-tokentypvärde. Värdet måste vara Bärare.
      • går ut om : Utgångstiden för åtkomsttoken.
      • omfattning: En eller flera mellanslagsseparerade strängar som anger vilken behörighet din applikation begär.

  • Resursbegäran

    • UserInfo-slutpunkten är en OAuth 2.0-skyddad resurs som returnerar anspråk om den autentiserade slutanvändaren. De returnerade anspråken representeras av ett JSON-objekt som innehåller en samling namn- och värdepar för anspråken.
    • Användarinfo begäran: Följande är ett icke-formativt exempel på en Userinfo-förfrågan: 
      •              FÅ http://<wp_base_url>/wp-json/moserver/resource
             Host: server.example.com
             Authorization: Bearer <access_token>
    • Lyckad användarinformationssvar:
    • UserInfo-kraven MÅSTE returneras som medlemmar i ett JSON-objekt.

      Nedan är exemplet: 
      •           { "id": "1", "username": "abc", "first_name": "xyz", "last_name": "example", "picture": "https://example.com/-kwtzesU/photo .jpg", "email": "abc@example.com", "locale": "en",... }

Bevilja lösenord

  • Beviljandetypen för resursägarens lösenord (eller "lösenord") används oftast i fall där appen är mycket betrodd. I den här konfigurationen anger användaren sina resursserveruppgifter (användarnamn/lösenord) till klientappen, som skickar en åtkomsttokenbegäran.

  • Token-förfrågan

    • Lösenordsbeviljandet är ett av de enklaste OAuth-beviljandena och involverar bara ett steg: applikationen presenterar ett traditionellt inloggningsformulär för användarnamn och lösenord för att samla in användarens inloggningsuppgifter och gör en POST-begäran till servern för att byta lösenordet mot en åtkomsttoken. POST-begäran som applikationen gör ser ut som exemplet nedan. 
      •           POST http://<wp_base_url>/wp-json/moserver/token
          Host: authorization-server.com
          Content-type: application/x-www-form-urlencoded
  
          grant_type=password
          &username=exampleuser
          &password=12345678
          &client_id=xxxxxxxxxx
          &client_secret=xxxxxxxxxx
    • POST-parametrarna i denna begäran förklaras nedan.
      • grant_type=lösenord : Detta talar om för servern att vi använder lösenordstypen
      • användarnamn= Användarens användarnamn som de angav i applikationen
      • password = Användarens lösenord som de angav i applikationen
      • client_id= Den offentliga identifieraren för applikationen som utvecklaren erhöll under registreringen
      • client_secret= Klienthemligheten som tillhandahålls av OAuth-leverantören.
    • Vid token-slutpunkten verifieras alla parametrar i begäran, vilket säkerställer att koden inte har gått ut och att klient-ID och hemlighet matchar. Om begäran lyckas genereras en åtkomsttoken och returneras i svaret: 
      •             HTTP/1.1 200 OK Content-Type: application/json Cache-Control: no-store { "access_token":"hkjher92u9eu2u3uihi2eh9293", "token_type":"bärare", "expires_in":3600, "scope":"profile", "id_token":"" }
    • Klienten kan sedan använda åtkomst_token för att komma åt skyddade resurser från resursservern.
      Här är beskrivningen för varje parameter som tas emot i svaret.
      • access_token : åtkomsttoken för Userinfo-slutpunkten.
      • token_type : OAuth 2.0-tokentypvärde. Värdet måste vara Bärare.
      • går ut om : Utgångstiden för åtkomsttoken.
      • omfattning: En eller flera mellanslagsseparerade strängar som anger vilken behörighet din applikation begär.

  • Resursbegäran

    • UserInfo-slutpunkten är en OAuth 2.0-skyddad resurs som returnerar anspråk om den autentiserade slutanvändaren. De returnerade anspråken representeras av ett JSON-objekt som innehåller en samling namn- och värdepar för anspråken.
    • Användarinfo begäran: Följande är ett icke-formativt exempel på en Userinfo-förfrågan: 
      •              FÅ http://<wp_base_url>/wp-json/moserver/resource
             Host: server.example.com
             Authorization: Bearer <access_token>
    • Lyckad användarinformationssvar:
    • UserInfo-kraven MÅSTE returneras som medlemmar i ett JSON-objekt.

      Nedan är exemplet: 
      •           { "id": "1", "username": "abc", "first_name": "xyz", "last_name": "example", "picture": "https://example.com/-kwtzesU/photo .jpg", "email": "abc@example.com", "locale": "en",... }

Beviljande av kunduppgifter

  • Klientautentiseringsuppgifter kan användas för maskin-till-maskin-autentisering. I detta tillstånd auktoriseras inte en specifik användare utan autentiseringsuppgifterna verifieras och en generisk access_token returneras.

  • Token-förfrågan

    • För att ta emot en åtkomsttoken skickar klienten ett API-anrop med värdena för klient-ID och klienthemlighet som hämtats från en registrerad utvecklarapp enligt följande. 
      •           POST http://<wp_base_url>/wp-json/moserver/token
              Content-Type: application/x-www-form-urlencoded
         
              grant_type=client_credentials&
              client_id=<client_id>&
              client_secret=<clientSecret>&
              redirect_uri=<redirect_uri>&
              scope=<permisssions_requested>

    • Begäran parametrar:
      • POST-begärans parametrar förklaras nedan.
      • grant_type=client_credentials : Detta anger för servern att vi använder klientuppgifter av typen beviljande.
      • client_id= Den offentliga identifieraren för applikationen som utvecklaren erhöll under registreringen.
      • client_secret: Klienthemligheten som tillhandahålls av OAuth-leverantören.
      • redirect_uri : Återanrops-URL som användaren omdirigeras till när de tillåter eller nekar åtkomst till din app.
      • omfattning: En eller flera mellanslagsseparerade strängar som anger vilken behörighet din applikation begär.
    • Om autentiseringsuppgifterna är giltiga kommer applikationen att få tillbaka en signerad JSON-webbtoken eller åtkomsttoken, tokens typ (som är Bearer) och hur lång tid den löper ut i Unix-tid.
    • Exempel på svar
      •         { "access_token": , "expires_in": 600, "token_type": "Bärare" }
    • Svarselement:
      • access_token : åtkomsttoken för Userinfo-slutpunkten.
      • upphör att gälla om Utgångstiden för åtkomsttoken.
      • token_type: OAuth 2.0-tokentypvärde. Värdet måste vara Bärare.

  • Resursbegäran

    • Ocuco-landskapet Beviljande av kunduppgifter stöder inte Resursbegäran.

    Uppdatera Token Grant

    • En uppdateringstoken gör det möjligt för applikationen att utfärda en ny åtkomsttoken eller ID-token utan att användaren behöver autentiseras på nytt. Detta fungerar så länge uppdateringstoken inte har återkallats.

    • Token-förfrågan

      • Svaret på tokenbegäran bör innehålla en åtkomsttoken och en uppdateringstoken. 
        •             { "access_token": "etMv23....429hiU32Hri", "refresh_token": "GEbRxBN...edjnXbL", "token_type": "Bärare" }
      • Använd en uppdateringstoken:
      • För att byta ut uppdateringstoken du fått mot en ny åtkomsttoken, gör en POST-begäran till tokenslutpunkten med hjälp av grant_type=refresh_token som följer. 
        •               POST http://<wp_base_url>/wp-json/moserver/token
              Content-Type: application/x-www-form-urlencoded
              grant_type=refresh_token&
              client_id=<client_id>&
              client_secret=<client_secret>&
              refresh_token=<refresh_token>
      • Här är beskrivningen för varje begäran parameter.
        • grant_type=refresh_token : Detta talar om för servern att vi använder beviljandetypen för uppdateringstoken.
        • client_id= Den offentliga identifieraren för applikationen som utvecklaren erhöll under registreringen.
        • client_secret: Klienthemligheten som tillhandahålls av OAuth-leverantören.
        • refresh_token : Uppdateringstoken att använda.
      • Svaret kommer att innehålla en ny Access Token, dess typ, dess livslängd (i sekunder) och de beviljade omfången. Om omfånget för den ursprungliga token inkluderade openid, kommer även en ny ID-token att finnas i svaret.
      • Svaret kommer att innehålla parametrar enligt följande:
        •             { "access_token": "eyJ...MoQ", "expires_in": 86400, "scope": , "id_token": "eyJ...0NE", "token_type": "Bärare" }

    Återkalla en uppdateringstoken

    • Eftersom Refresh Tokens aldrig går ut är det viktigt att kunna återkalla dem om de blir komprometterade.
    • För att återkalla en Refresh Token kan du skicka en POST begäran till token-slutpunkten enligt följande. 
      •             POST http://<wp_base_url>/wp-json/moserver/token
            Content-Type: application/x-www-form-urlencoded
            client_id=<client_id>&
            client_secret=<client_secret>&
            refresh_token=<refresh_token>

Gratis provperiod

Om du inte hittar det du söker, vänligen kontakta oss på info@miniorange.com eller ring oss på +1 978 658 9387 för att få svar på din fråga om Wordpress OAuth-server.

Titta på videorna för att lära dig mer  Titta på Demo
Hej där!

Behövs hjälp? Vi är här!

stödja
Populära sökningar: