Beviljande av auktoriseringskod
-
Behörighetsbegäran
-
Applikationen måste först bestämma vilka behörigheter den begär och sedan skicka användaren till en webbläsare för att få deras tillstånd. För att initiera 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å behörighetskod måste den ha ett värde
koda. Detta talar om för auktoriseringsservern att applikationen initierar auktoriseringsflödet.
Klient ID : Klient-ID som tillhandahålls av OAuth-leverantören.
redirect_uri : Återuppringningsadress till vilken användare kommer att omdirigeras när de tillåter eller nekar åtkomst till din app.
omfattning: En eller flera mellanslagsseparerade strängar som indikerar den behörighet som 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 webbläsaren att omdirigeras till den angivna omdirigeringsadressen och begäran inkluderar
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>
Smakämnen koda är auktoriseringskod som kan bytas ut mot Access token. Den genereras av auktoriseringsservern och är relativt kortlivad.
Smakämnen 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 tokenslutpunkten.
- 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 : Vilken typ av bidrag du ger. Detta talar om att applikationen använder behörighetskod beviljande typ.
-
kod: Auktoriseringskoden som erhölls i föregående steg, inkluderad här.
-
redirect_uri: Samma uri som angavs tidigare i auktoriseringsbegäran.
-
Klient ID : Klient-ID som tillhandahålls av OAuth-leverantören.
-
client_secret : Klienthemligheten som tillhandahålls av OAuth-leverantören.
Vid token-slutpunkten kommer alla parametrar i begäran att verifieras för att säkerställa att koden inte har gått ut och klient-id och hemlighet matchar. Om begäran lyckas genererar den en åtkomsttoken och returnerar den 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 : Värde av OAuth 2.0-tokentyp. Värdet måste vara Bärare.
-
går ut om : Utgångstiden för åtkomsttoken.
-
omfattning: En eller flera mellanslagsseparerade strängar som indikerar den behörighet som 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 vid användning av en klient, och eventuellt 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å Userinfo Request:
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 som 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 av 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 måste först bestämma vilka behörigheter den begär och sedan skicka användaren till en webbläsare för att få deras tillstånd. För att initiera 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 applikationen initierar ett implicit flöde. Notera skillnaden från flödet för auktoriseringskod där detta värde är inställt på kod.
Klient ID : Klient-ID som tillhandahålls av OAuth-leverantören.
redirect_uri : Återuppringningsadress till vilken användare kommer att omdirigeras när de tillåter eller nekar åtkomst till din app.
omfattning: En eller flera mellanslagsseparerade strängar som indikerar den behörighet som 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 webbläsaren att omdirigeras till den angivna omdirigeringsadressen och begäran inkluderar
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>
Notera 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 : Värde av OAuth 2.0-tokentyp. Värdet måste vara Bärare.
-
går ut om : Utgångstiden för åtkomsttoken.
-
omfattning: En eller flera mellanslagsseparerade strängar som indikerar den behörighet som din applikation begär.
Resursbegäran
-
UserInfo Endpoint ä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å Userinfo Request:
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 av 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
-
Resursägarlösenordet (eller "lösenord") beviljandetyp används oftast i fall där appen är mycket pålitlig. I den här konfigurationen tillhandahåller användaren sina resursserveruppgifter (användarnamn/lösenord) till klientappen, som skickar dem i en begäran om åtkomsttoken.
-
Token-förfrågan
-
Lösenordsbeviljande är ett av de enklaste OAuth-beviljanden och omfattar bara ett steg: applikationen presenterar ett traditionellt användarnamn och lösenordsinloggningsformulär för att samla in användarens autentiseringsuppgifter 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 typen av lösenordsbeviljande
-
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 fick under registreringen
-
client_secret= Klienthemligheten som tillhandahålls av OAuth-leverantören.
Vid token-slutpunkten kommer alla parametrar i begäran att verifieras för att säkerställa att koden inte har gått ut och klient-id och hemlighet matchar. Om begäran lyckas genererar den en åtkomsttoken och returnerar den 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 : Värde av OAuth 2.0-tokentyp. Värdet måste vara Bärare.
-
går ut om : Utgångstiden för åtkomsttoken.
-
omfattning: En eller flera mellanslagsseparerade strängar som indikerar den behörighet som din applikation begär.
Resursbegäran
-
UserInfo Endpoint ä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å Userinfo Request:
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 av 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
-
Beviljande av klientuppgifter kan användas för maskin-till-maskin-autentisering. I det här tillståndet är en specifik användare inte auktoriserad utan istället verifieras inloggningsuppgifterna och en generisk access_token returneras.
-
Token-förfrågan
-
För att få en åtkomsttoken POSTAR klienten ett API-anrop med värdena för klient-ID och klienthemlighet som erhållits 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 talar om för servern att vi använder typen av beviljande av klientuppgifter.
-
client_id= Den offentliga identifieraren för applikationen som utvecklaren fick under registreringen.
-
client_secret: Klienthemligheten som tillhandahålls av OAuth-leverantören.
-
redirect_uri : Återuppringningsadress till vilken användare kommer att omdirigeras när de tillåter eller nekar åtkomst till din app.
-
omfattning: En eller flera mellanslagsseparerade strängar som indikerar den behörighet som din applikation begär.
Om referenserna är giltiga kommer applikationen att få tillbaka en signerad JSON Web Token eller åtkomsttoken, tokens typ (som är Bearer) och efter 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: Värde av OAuth 2.0-tokentyp. Värdet måste vara Bärare.
Resursbegäran
- Smakämnen Beviljande av kunduppgifter stöder inte Resursbegäran.
Uppdatera Token Grant
-
En Refresh Token tillåter applikationen att utfärda en ny åtkomsttoken eller ID-token utan att behöva autentisera användaren på nytt. Detta kommer att fungera så länge som Refresh Token inte har återkallats.
-
Token-förfrågan
-
Svaret på tokenbegäran bör innehålla åtkomsttoken och uppdateringstoken.
{ "access_token": "etMv23....429hiU32Hri", "refresh_token": "GEbRxBN...edjnXbL", "token_type": "Bärare" }
Använd en uppdateringstoken:
För att byta ut Refresh Token du fick mot en ny Access Token, gör en POST-begäran till token-slutpunkten 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 typen av uppdateringstoken.
-
client_id= Den offentliga identifieraren för applikationen som utvecklaren fick under registreringen.
-
client_secret: Klienthemligheten som tillhandahålls av OAuth-leverantören.
- refresh_token : Uppdateringstoken att använda.
Svaret kommer att inkludera en ny åtkomsttoken, dess typ, dess livslängd (i sekunder) och de beviljade omfattningarna. Om omfattningen av den initiala token inkluderade openid, kommer ett nytt ID-token också 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 upphör att gälla, är det viktigt att kunna återkalla dem ifall de äventyras.
-
För att återkalla en Refresh Token kan du skicka en POST begäran till token endpoint 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>
Pröva På
Om du inte hittar det du letar efter, vänligen kontakta oss på
info@miniorange.com
Eller ring oss på +1 978 658 9387 för att hitta svar på din fråga om Wordpress OAuth Server.
Titta på videorna för att lära dig mer
Titta på Demo
