integracija aplikacije v centralni idp rekono sistem z

34
1 INTEGRACIJA APLIKACIJE V CENTRALNI IDP REKONO SISTEM Z UPORABO OPENID CONNECT 1.0 PROTOKOLA Tehnični opis integracije Podatki dokumenta Naslov: Integracija aplikacije v sistem Rekono prek openid connect protokola Datum: 2018-03-28 Avtor: Marko Šmid Referenca: Rekono-App Datoteka: Rekono-OIDC.docx Upravitelj Person Podpis Datum Vloga Avtor Marko Šmid Projektni vodja Nadzornik Miha Poberaj Svetovalec Upravljanje dokumenta Vodenja sprememb dokumenta Datum Verzija Avtor Opis sprememb 2017-09-21 0.9 Marko Šmid Osnutek 2017-11-02 0.9.5 Marko Šmid Dopolnitev navodil uporabe Rekono OIDC storitve 2018-01-06 1.0 Marko Šmid Dopolnitev navodil 2018-03-28 1.1 Marko Šmid Dopolnitev navodil s poglavjem “Opis /userinfo klica

Upload: others

Post on 18-Nov-2021

3 views

Category:

Documents


0 download

TRANSCRIPT

1

INTEGRACIJA APLIKACIJE V CENTRALNI IDP REKONO SISTEM Z UPORABO OPENID CONNECT 1.0 PROTOKOLATehnični opis integracije

Podatki dokumentaNaslov: Integracija aplikacije v sistem Rekono prek openid connect protokolaDatum: 2018-03-28Avtor: Marko ŠmidReferenca: Rekono-AppDatoteka: Rekono-OIDC.docx

Upravitelj Person Podpis Datum VlogaAvtor Marko Šmid Projektni vodjaNadzornik Miha Poberaj Svetovalec

Upravljanje dokumenta

Vodenja sprememb dokumenta

Datum Verzija Avtor Opis sprememb2017-09-21 0.9 Marko Šmid Osnutek

2017-11-02 0.9.5 Marko Šmid Dopolnitev navodil uporabe Rekono OIDCstoritve

2018-01-06 1.0 Marko Šmid Dopolnitev navodil

2018-03-28 1.1 Marko Šmid Dopolnitev navodil s poglavjem “Opis /userinfo klica”

OSI d.o.o.

Veljaven: različica 1.1

Kazalointegracija aplikacije v centralni idp rekono sistem z uporabo openid connect 1.0 protokola......................................................................................................................1

Kazalo....................................................................................................................2Opis protokola OpenID Connect.............................................................................3Rekono podpora za openid Connect......................................................................3

Opis uporabe OpenID Connect protokola.....................................................................4Podrobnosti authorization code postopka..............................................................5

Korak 1: Kako pridobiti access_token?............................................................6Korak 2: zahteva za access_token s strani client aplikcije...............................7Korak 3: Klic RS strežnika (REST API) z access_token žetonom.......................8Korak 4: Kaj narediti ko access_token poteče?..............................................10

Opis varne izvedbe mobilne aplikacije.......................................................................12Varna prijava.......................................................................................................12Dostop do izjav o uporabniku, ki je lastnik access_token-a..................................16

Opis /userinfo klica........................................................................................18Pridobitev podatkov prek REST aplikacije............................................................20Uporaba refresh_token žetona.............................................................................21

Napaka ob klicu refresh_token zahteve.........................................................24Preklic ŽETONA....................................................................................................24Rekono OIDC Single Sign On in upravljanje sej (če je potrebno)..........................25

Upravljanje Rekono openid odjemalcev......................................................................29Uporabniški račun(i) končne stranke...................................................................29Registracija novega odjemalca............................................................................29

Reference...................................................................................................................31OpenID connect 1.0......................................................................................31OpenID connect PKCE dodatna zaščita.........................................................31OpenID connect upravljanje seje...................................................................31OpenID varnost in nedosledna implementacija.............................................31Refresh token................................................................................................31Uporaba mobile client knjižnic......................................................................31Facebook varnostna priporočila za varno uporabo oauth2 in openidConnect......................................................................................................................31Google priporočila varne avtentikacije z zalednim RS strežnikom.................31OWASP certifcate pinning.............................................................................32PUSH notifcations.........................................................................................32id_token timeout...........................................................................................32Google OpenidConnect and OAUTH2............................................................32JWT, JWK........................................................................................................32Rekono Authrization ConnectRequestParameters.........................................33

Rekono OIDC 2/34

OSI d.o.o.

Veljaven: različica 1.1

Opis protokola OpenID ConnectProtokol openid connect je nadgradnja oauth2 protokola z dodatnim slojem e-identitete. Omogoča odjemalcem da preverijo identiteto končnega uporabnika z avtetikacijo na Athorization Server-ju (AS), kot tudi da prejmejo osnovni profl uporabnika.

OpenID Connect omogoča vse vrstam odjemalcev, vključujoč spletne odjemalce, mobilne, Javascript, da zahtevajo in pridobijo informacije o avtenticiranem uporabniku. OpenID conect specifkacija je odprta in omogoča odprti nabor atributov in tudi lastnosti izmenjave podatkov z opcijsko uvedbo enkripcije podatkov o identiteti in možnostjo samodejnega odkrivanja informacij o OpenID ponudniku.

Več podrobnosti o specifkaciji je na voljo na povezavah na spletišču http://openid.net/connect/.

OpenID Connect defnira RESTful HTTP API z uporabo JSON oblike prenosa podatkov.

Rekono podpora za openid ConnectRekono podpira OpenID connect 1.0 z naslednjimi lastnostmi:

Authorization code foo Implicit foo UserInfo endpoint Manual client management through an administrator console Client authentication through form parameters, HTTP Basic, and public key

JWT assertion Webfnger discovery endpoint OpenID Confguration discovery endpoint JWK Set public key endpoint Standard scopes: openid, phone, address, email, profle, and ofine_access Additional arbitrary scopes Refresh tokens ID Tokens Signed JWT access tokens RSA Signing (used for all tokens) RSA Encryption HMAC Signing Dynamic registration endpoint Request Objects (signed) Introspection Endpoint Revocation Endpoint Token chaining PKCE support

Rekono OpenID Connect je na voljo na URL-ju https://idp.rekono.si/openid-connect-server-oebapp/. Pod tem URL-jem so dostopne posamezne vstopne točke protokola:

Authorization endpoint: /authorize Token endpoint: /token Token introspection: /introspect Token revocation: /revoke JSON Web Key Set (public key): /jok

Rekono OIDC 3/34

OSI d.o.o.

Veljaven: različica 1.1

User info: /userinfo Provider confguration: /.oell-knoon/openid-confguration Dynamic Client Registration: /register

Testno okolje za testiranje integracije aplikacij je razvijalcem na voljo na URL naslovu:https://idptst.rekono.si/openid-connect-server-oebapp/ in pod povezavah za posamezne vstopne točke.

Vsi URL-ji zahtev v nadaljevanju vsebujejo primere na testnem sistemu https://idptst.rekono.si/openid-connect-server-webapp/

OPIS UPORABE OPENID CONNECT PROTOKOLAOsnovni delovni tok pri openID connect protokolu je prikazan na spodnjih dveh diagramih.

Implicit delovni tok je namenjen za aplikacije in spletišča, ki nimajo logike na strežniški spletni aplikaciji. Vse izmenjanje informacije med OpenId ponudnikom (OpebId Provider) (v terminologiji oauth2 poimenovan tud Authorization Server: AS) in aplikacijo so v aplikaciji vidne in dostopne.

V koraku 1, uporabnik želi sejo v Client (RP) aplikaciji. Zato je preusmerjen na OpenIDponudnika ali avtorizacijski strežnik. Client aplikacija se v zahtevi, ki jo posreduje OpenID ponudniku, predstavi z enoznačnim id-jem in geslom. V koraku 2 se uporabnik avtenticira in strinja s posredovanjem podatkov končni aplikaciji (Client). Vkoraku 3 OpenID ponudnik informacije o uporabniku zakodira v id_token v JWT obliki. id_token vsebuje uporabiške podatke (scopes v Oauth terminologiji) in podpis (z npr. uporabo RS256). OpenID ponudnik uporabniak preusmeri nazaj na Client aplikacijo naURL, ki je preddoločen za določeni aplikacijo. V koraku 4, Client aplikacija prebere JWT id_token in preveri veljavnost podpisa z uporabo javnega ključa OpenID

Rekono OIDC 4/34

Slika 1: Implicit delovni tok

OSI d.o.o.

Veljaven: različica 1.1

ponudnika. Če je vse OK, je na strani Client aplikacije vzpostavljena seja.

Varnost je zagotovljena s podpisovanjem in opcijsko šifriranjem id_token JWT žetona in z v naprej določenim URL-jem na katerega -OpenID ponudnik vrne uporabnika.

Authorization code pristop se uporabi za aplikacije, ki imajo zaledno strežniško logiko,ki lahko komunicira po ločenem “kanalu” z OpenID ponudnikom. V tem delotoku gre za klasično tripartitno izmenjavo, kjer končna strežniška aplikacija ne dobi uporabniških avtentikacijskih mehanizmov, ampak prejme avtorizacijsko kodo (authorization_code), ki jo potem lahko zamenja za vstopni žeton (access_token). Na osnovi access_token-a pa lahko končna strežniška aplikacija pridobi podatke o uporabniku.

V koraku 1 uporabnik želi pridobiti veljavno sejo na Client aplikaciji in je preusmerjen na OpenID ponudnika, pri čemer končna aplikacija pošlje tudi avtentikacijske podatkeaplikacije: client_id in client_secret. V koraku 2 OpenID ponudnik avtenticira uporabnika in potrdi strinjanje za Client aplikacijo, da lahko dostopa do njegovih podatkov eID profla. Namesto podatkov eID profla pa OpenID ponudnik vrne v koraku 3 Client aplikaciji avtorizacisjko kodo (authorization_code) na v naprej določenURI. V koraku 4, strežnik Client aplikacije posreduje authorization_code, da prejme začasni vstopni žeton (access_token). Trajanje veljavnost žetona je odvisna od več parametrov. V koraku 5 Client aplikacija prejme access_token da dostopa do eID profla uporabnika in/ali ustreznega sredstva do katerega je uporabnik dovolil dostop v koraku 2.

Podrobnosti authorization code postopkaclient_id je enoznačna oznaka aplikacije. client_secret je geslo ozrima skrivnost client_id aplikacije. Obe informaciji pridobi aplikacija ali lastnik aplikacije pri OpenID ponudniku ob registraciji ali ob samoregistraciji. Oba podatka se enako uporabljata tako v mobilnih aplikacijah, kot tudi v spletni strežniški aplikaciji. Zato je potrebno oba podatka obravnavati kot podatka, ki sta lahko “odtujena”.

Rekono OIDC 5/34

Slika 2: Authorization code Flow

OSI d.o.o.

Veljaven: različica 1.1

Ključna vprašanja za razvijalca so:1. kako prejeti in obnoviti vstopni žeton (access_token);2. kdaj, kako in kje hraniti refresh_token;3. kako dodatno zaščititi eID profl (JWT žeton);4. kako zahtevati omejeno veljavnost access_token-a?5. Kako dodatno zaščititi izmenjavo openID RESTful paketov: PKCE, code_verifer;

Korak 1: Kako pridobiti access_token?

Prva zahteva, ki jo pošlje aplikacija, ki želi pridobiti access_token je preusmeritev uporabnika na URL openID providerja.

GET https://idptst.rekono.si/openid-connect-server-oebapp/authorize?response_type=code&client_id=0dca8539-99b7-4712-ba6e-f70bdeaa40af&scope=rekonoID+naslov+address+phone+openid+profle+ofine_access+email&redirect_uri=https://cestst.subscribo.si/sample-oeb-app/openid_connect_login&nonce=2c41e43a904eb&state=5cf1637d6f7d

Opis parametrov osnovne zahteve:

response_typecodeclient_id 0dca8539-99b7-4712-ba6e-f70bdeaa40af

scope rekonoID+naslov+address+phone+…+profle+ofine_access+email

redirect_uri https://cestst.subscribo.si/sa…-oeb-app/openid_connect_loginnonce 2c41e43a904ebstate 5cf1637d6f7d

Parameter Opis

state

The state parameter se uporablja za zmanjšanje možnosti Cross Site Request Forgery (XSRF) napadov. AS strežnik oziroma OpenID ponudnik bo vrnil to vrednost nespremnjeno, ko bo preusmeril uporabnika nazajna aplikacijo na redirect_uri. Odjemalska aplikacija mora zagotoviti preverjanje odgovora in ujemanje zahteve z odgovorom, prek state parametra.

response_type Vrednost “code” pomeni da gre za tip zahteve “OAuth 2.0 authorizationcode grant”.

scopeSeznam zahtev, ki jih ima aplikacija do uporabnikovih sredstev oziroma podatkov.

client_id Predstavlja enoznačno identifikacijo client aplikacije, ki jo je skrbnik ali aplikacija prejela od AS strežnika.

redirect_uriPredstavlja URL na katerega mora AS vrniti uporabnika po uspešni avtentikaciji. Za mobile aplikacije je URI splošen URI v obliki npr. si.company.mobile_app://oidc/callback

Dodatni parametri code zahteve:

Rekono OIDC 6/34

OSI d.o.o.

Veljaven: različica 1.1

Parameter Opis

code_challenge

Zahtevano za “Proof Key for Code Exchange” (PKCE) razširitev. Ta parameter je podoben parameter kot state parameter, samo da v primeru, ko odjemalec doda pkce code_challenge zahtevo, AS izda žetone, le za zahtevo, ki pošlje odgovarjajoči code_verifier podatek. code_challenge je plain podatek ali sha256 hash povzetek code_verifier enkratne kode. code_verifier je vsaj 43 znakov dolgaenkratna koda v url-encoded formatu, code_challenge pa je base64 kodiran povzetek. Glej spodaj….

code_challenge_method

V primeru da je code_challenge_method=plain code_verifier = code_challenge

code_challenge_method=S256 code_challenge=BASE64URL-ENCODE(SHA256(ASCII(code_verifier)))

Ko se uporabnik avtenticira na OpenID provider (AS) strežniku ga po uspešni avtentikaciji in potrditvi strinjanja (consent) openID vrne na redirect_uri URL. redirect_uri naj se preveri na AS strežniku, če odgovarja registriranemu redirect_uri-ju.

V odovoru je vsebovana avtorizacijska koda in preusmeritev na redirect_uri.

HTTP/1.1 302 FoundDate: Thu, 05 Oct 2017 06:21:39 GMTServer: Apache/2.4.6 (CentOS) OpenSSL/1.0.1e-fps mod_jk/1.2.40Cache-Control: no-cache, no-store, max-age=0, must-revalidatePragma: no-cacheExpires: 0Strict-Transport-Security: max-age=31536000 ; includeSubDomainsX-XSS-Protection: 1; mode=blockX-Frame-Options: DENYX-Content-Type-Options: nosnifLocation: https://cestst.subscribo.si/sample-web-app/openid_connect_login?code=HIBjRh&state=5cf1637d6f7eContent-Language: slContent-Length: 0Keep-Alive: timeout=5, max=100Connection: Keep-Alive

Korak 2: zahteva za access_token s strani client aplikcije

Cleint brooser prejme authorisation_code grant žeton (code v 302 preusmeritvi). Ta grant žeton client aplikacija uporabi da zahteva access_token žeton:

POST https://idptst.rekono.si/openid-connect-server-oebapp/tokenAuthorization: Basic Q09NUEFOWVhcdXNlcjE6cGFzc3dvcmQxMjM={ "grant_type":"authorization_code",

Rekono OIDC 7/34

OSI d.o.o.

Veljaven: različica 1.1

"code":"SplxlOBeZQQYbYS6WxSbIA", "redirect_uri":"https://client.example.com/cb"}

Avtorizacijo client app izvede s client_id:client_secret.

Strežnik tvori odgovor v katerem pošlje access_token in v primeru zahteve s scope parametrom profile tudi id_token. id_token vsebuje informacije o elektronski identitetiuporabnika in v namenjen client app, da pridobi informacije o avtenticiranem uporabniku. access_token client app uporabi za klic RS (Resource Server) strežnika (strežnika, ki vrne podatke aplikaciji povezane z uporabnikom), katerega RS strežnik uporabi za serviranje vsebine, ki jo vrne za avtenticiranega uporabnika. Z access_token-om client app pridobi dovoljenje lastnika, da RS strežnik laho dostopa do podatkov uporabnika.

Odgovor AS strežnika:HTTP/1.1 200 OKContent-Type: application/json{ "id_token": "eyJhbGciOiJSUzI1NiIsImtpZCI6IjFlOWdkazcifQ.eoogImlzc yI6ICJodHRoOi8vc2VydmVyLmV4YW1obGUuY29tIioKICJzdWIiOiAiMjQ4Mjg5 NzYxMDAxIioKICJhdWQiOiAiczZCaGRSa3F0MyIsCiAibm9uY2UiOiAibi0oUzZ fV3pBMk1qIioKICJleHAiOiAxMzExMjgxOTcoLAogImlhdCI6IDEzMTEyODA5Nz AKfQ.ggW8hZ1EuVLuxNuuIJKX_V8a_OMXzR0EHR9R6jgdqrOOF4daGU96Sr_P6q Jp6IcmD3HP99Obi1PRs-coh3LO-p146oaJ8IhehcoL7F09JdijmBqkvPeB2T9CJ NqeGpe-gccMg4vfKjkM8FcGvnzZUN4_KSP0aAp1tOJ1zZogjxqGByKHiOtX7Tpd QyHE5lcMiKPXfEIQILVq0pc_E2DzL7emopWoaoZTF_m0_N0YzFC6g6EJbOEoRoS K5hoDalrcvRYLSrQAZZKfyuVCyixEoV9GfNQC3_osjzo2PAithfubEEBLuVVk4 XUVrWOLrLl0nx7RkKU8NXNHq-rvKMzqg" "access_token":"2YotnFZFEjr1zCsicMWpAA", "token_type":"bearer", "expires_in":3600, "refresh_token":"tGzv3JOkF0XG5Qx2TlKWIA"}

id_token je v JWT formatu in mora biti preverjen s strani client aplikacije. Preverjanje se izvede prek preverjanja podpisa, ki ga je dodal openid AS strežnik.

Korak 3: Klic RS strežnika (REST API) z access_token žetonomEna od možnosti za klic strežnika z viri podatkov (resource server = RS) s strani odjemalca je klic z avtentikacijo z Bearer avtorizacijskim žetonom v glavi HTTP zahteve.

Bearer žeton je lahko access_token ali JWT token, ki ga odjemalec pošlje RS strežniku v Authorization: Bearer glavi:

GET /rest_api_v1/1 HTTP/1.1Host: resource.osi.siAuthorization: Bearer 2YotnFZFEjr1zCsicMWpAA

Korak 1: RS srežnik preveri veljavnost access_token žetona, ki ga je prejel v glavi

Rekono OIDC 8/34

OSI d.o.o.

Veljaven: različica 1.1

zahteve v Authorization parametru. access_token client app posreduje RS strežniku.

RS strežnik preveri veljavnost access žetona na RS strežniku prek klicahttps://idptst.rekono.si/openid-connect-server-oebapp/introspect/

s parmetri:token=”vrednost žetona, ki ga preverjamo”

AS strežnikov odgovor je npr.:{ "active": true, "scope": "", "expires_at": "2016-11-15T13:45:27+0800", "exp": 1479188727, "sub": "109d9952-8eae-48a4-8516-4af6fde52616", "user_id": "109d9952-8eae-48a4-8516-4af6fde52616", "client_id": "client1", "token_type": "Bearer"}

curl -k -i -u "ef523e8a-460c-414e-88b3-de134e4480a0:Ir4WAlnrSO60OMRNQUZ9_dbOxjevTjOTrLgUeiKouNSE8DsUECnG0JMQ86vdYUCIAjlIsEniOgQQRIB4JzM_Bg" -d "token=eyJraWQiOiJyc2ExIioiYWxnIjoiUlMyNTYifQ.eyJzdWIiOiJtYXJrby5zbWlkQG9zaS5zaSIsImF6cCI6IjVjNjAxMTc5LTYyYWYtNDRiNy1iM2RmLTY5Njk3M2Q2YjcxYiIsImlzcyI6Imh0dHBzOlovXC9pZHB0c3QucmVrb25vLnNpXC9vcGVuaWQtY29ubmVjdC1zZXJ2ZXItd2ViYXBoXC8iLCJleHAiOjE1MDg4ODk4NzcsImlhdCI6MTUoODg4NjI3NyoianRpIjoiYzA2MzA0OTItNDZiZC00MWMxLTllMTAtODdhODg2MTMyODE1In0.WAkzW9MzzgUQDNEAAm-mRBxtUEa_RqN68ckfWz2M6o2jOOVbuecoVB9rlOEWyn76EoNV0Ed12vkZmddJtP8uEHtM3FGhQRorBrAAS24P5KnibS3g5DQVYQzo_2ihLg6eClyLh-A7xHbZh8JniqFsr3cTIxpf658LhP5UAG3QSfUgBla3HPE3IXG39igQ5bVa5bb2XUKRrmQ8UGOOtKWi_cvyuGgJg7LiMbRRJhoo4j66pUhHiebQDi24K1HFp6WqUNGUUj6psljNh9l3sy1kvAlo19dSnenMgUoLTiHvPMKc8o0WXcNOm1u-ylfmkiaasyxArToGZWB6LBqVrj_mZo" -H "Content-Type: application/x-ooo-form-urlencoded" https://idptst.rekono.si/openid-connect-server-oebapp/introspect

HTTP/1.1 200 OKDate: Tue, 24 Oct 2017 23:31:20 GMTServer: ApacheAccess-Control-Alloo-Origin: *Cache-Control: no-cache, no-store, max-age=0, must-revalidatePragma: no-cacheExpires: 0Strict-Transport-Security: max-age=31536000 ; includeSubDomainsX-XSS-Protection: 1; mode=blockX-Frame-Options: DENYX-Content-Type-Options: nosnifContent-Language: slContent-Length: 277Content-Type: application/json;charset=UTF-8

{"active":true,"scope":"address phone openid profle http://idp.rekono.si/openid/taxnumber email","expires_at":"2017-10-25T02:04:37+0200","exp":1508889877,"sub":"3854901295","user_id":"[email protected]","client_id":"5c601179-62af-44b7-b3df-696973d6b71b","token_type":"Bearer"}

Iz odgovora je razvidno, da gre za veljaven žeton, ki je bil izdan za “ 5c601179-62af-44b7-b3df-696973d6b71b” aplikacijo, za uporabnika user_id. user_id je enoznačen podatek uprabnika, ravno tako podatek sub. Oba podatka lahko RS uporabi, da pridobi podatke, ki jih uporabi za dostop do podatkov uporabnika.

Rekono OIDC 9/34

OSI d.o.o.

Veljaven: različica 1.1

Na ta način ima RS aplikacija informacijo o uporabniku , ki je preverjena in lahko streže podatke client app aplikaciji.

access_token ima kratkotrajno veljavnost in ga je potrebno obnoviti oziroma mora odjemalec posredovati nov access_token žeton, ko prejšnji poteče.

Primer klica preverjanja pretečenega žetona:curl -k -i -u "ef523e8a-460c-414e-88b3-de134e4480a0:Ir4WAlnrSO60OMRNQUZ9_dbOxjevTjOTrLgUeiKouNSE8DsUECnG0JMQ86vdYUCIAjlIsEniOgQQRIB4JzM_Bg" -d "token=eyJraWQiOiJyc2ExIioiYWxnIjoiUlMyNTYifQ.eyJzdWIiOiJtYXJrby5zbWlkQG9zaS5zaSIsImF6cCI6IjVjNjAxMTc5LTYyYWYtNDRiNy1iM2RmLTY5Njk3M2Q2YjcxYiIsImlzcyI6Imh0dHBzOlovXC9pZHB0c3QucmVrb25vLnNpXC9vcGVuaWQtY29ubmVjdC1zZXJ2ZXItd2ViYXBoXC8iLCJleHAiOjE1MDg4ODk4NzcsImlhdCI6MTUoODg4NjI3NyoianRpIjoiYzA2MzA0OTItNDZiZC00MWMxLTllMTAtODdhODg2MTMyODE1In0.WAkzW9MzzgUQDNEAAm-mRBxtUEa_RqN68ckfWz2M6o2jOOVbuecoVB9rlOEWyn76EoNV0Ed12vkZmddJtP8uEHtM3FGhQRorBrAAS24P5KnibS3g5DQVYQzo_2ihLg6eClyLh-A7xHbZh8JniqFsr3cTIxpf658LhP5UAG3QSfUgBla3HPE3IXG39igQ5bVa5bb2XUKRrmQ8UGOOtKWi_cvyuGgJg7LiMbRRJhoo4j66pUhHiebQDi24K1HFp6WqUNGUUj6psljNh9l3sy1kvAlo19dSnenMgUoLTiHvPMKc8o0WXcNOm1u-ylfmkiaasyxArToGZWB6LBqVrj_mZo" -H "Content-Type: application/x-ooo-form-urlencoded" https://idptst.rekono.si/openid-connect-server-oebapp/introspect

HTTP/1.1 200 OKDate: Wed, 25 Oct 2017 00:09:28 GMTServer: ApacheAccess-Control-Alloo-Origin: *Cache-Control: no-cache, no-store, max-age=0, must-revalidatePragma: no-cacheExpires: 0Strict-Transport-Security: max-age=31536000 ; includeSubDomainsX-XSS-Protection: 1; mode=blockX-Frame-Options: DENYX-Content-Type-Options: nosnifContent-Language: slContent-Length: 16Content-Type: application/json;charset=UTF-8

{"active":false}

Korak 4: Kaj narediti ko access_token poteče?Ko poteče access_token ima client app dve možnosti:1) zahteva nov access_token prek refresh_token-a;2) uporabnika usmeri na AS strežnik da se ponovno avtenticira;

Pri uporabi refresh_token-a je potrebno biti previden. Client app mora varno hraniti refresh_token. Refresh_token je žeton s katerim client app dobi novo “vstopnico” do želenega vira (podatkov).

Primer klica client app applikacije za obnovitev access_token žetona:POST https://idptst.rekono.si/openid-connect-server-oebapp/token' content-type: application/jsonPOST data "grant_type": "refresh_token", "client_id": "YOUR_CLIENT_ID", "client_secret": "YOUR_CLIENT_SECRET", "refresh_token": "YOUR_REFRESH_TOKEN"

V odgovoru AS strežnik vrne nov access_token, ki ga client_app uporabi pri klicu RS strežnika:

Rekono OIDC 10/34

OSI d.o.o.

Veljaven: različica 1.1

{ "access_token": "eyJ...MoQ", "expires_in": 3600, "scope": "openid ofine_access", "id_token": "eyJ...0NE", "token_type": "Bearer"}

Primer klica:curl -k -i -u "5c601179-62af-44b7-b3df-696973d6b71b:b_18bKVFZjDmEEdKBgpOtwF4KAmRFIpQkzFy4B-OVCG9OKUNGix8HPSqT3Bt_pxhbEnwCSGgubCpTAh43AH47A" -d "grant_type=refresh_token" -d"refresh_token=eyJhbGciOiJub25lIn0.eyJqdGkiOiJkOTdhMzk2YS0yNzc1LTRlNTItYTQzOC05ZWNkZGY4YzNjYjMifQ." -H "Content-Type: application/x-www-form-urlencoded" https://idptst.rekono.si/openid-connect-server-webapp/token

Odgovor AS strežnika:HTTP/1.1 200 OKDate: Wed, 25 Oct 2017 00:17:22 GMTServer: ApacheAccess-Control-Alloo-Origin: *Cache-Control: no-cache, no-store, max-age=0, must-revalidatePragma: no-cacheExpires: 0Strict-Transport-Security: max-age=31536000 ; includeSubDomainsX-XSS-Protection: 1; mode=blockX-Frame-Options: DENYX-Content-Type-Options: nosnifTransfer-Encoding: chunkedContent-Type: application/json;charset=UTF-8

{"access_token":"eyJraWQiOiJyc2ExIioiYWxnIjoiUlMyNTYifQ.eyJzdWIiOiJtYXJrby5zbWlkQG9zaS5zaSIsImF6cCI6IjVjNjAxMTc5LTYyYWYtNDRiNy1iM2RmLTY5Njk3M2Q2YjcxYiIsImlzcyI6Imh0dHBzOlovXC9pZHB0c3QucmVrb25vLnNpXC9vcGVuaWQtY29ubmVjdC1zZXJ2ZXItd2ViYXBoXC8iLCJleHAiOjE1MDg4OTQyNDIsImlhdCI6MTUoODg5MDY0MioianRpIjoiMzZiN2I1MWItZTg4MC00NmJjLWI2Y2EtOWJhN2FjNmZhYmY2In0.lvIFZfVhkzHTdoI97MfgXK7OQGmpSoQGHSFjyBrx7qd3_3xhB7e0MagutbFF1l01AxHvbeIcIbH_JbUBdn5d10rTtRPSSzhh5sOSqba6AQLJfCbSNfqQhLnOmdu8WhLBUygG1ZCqb3-pAsE56b7ZoYWhYrqG8BAl1LeTcvaE3vRt_INkvSATCJJzjov5bVgqfn2YDR50vxdZe3ReQqNACO3_OhxBX2acWEVn9ej28LfSyzBH7Dvr1B_tUt_PgyGi2FpYSQgmMht9KlNFHzT9b-uUv-dQJujcpFrc6M4jVDoaCWIi02KmSBe_SoD7U6PYTZVZW8_2gEIMXhOnZRk1g","token_type":"Bearer","refresh_token":"eyJhbGciOiJub25lIn0.eyJqdGkiOiJkOTdhMzk2YS0yNzc1LTRlNTItYTQzOC05ZWNkZGY4YzNjYjMifQ.","expires_in":3599,"scope":"naslov rekonoID address phone openid ofine_access profle http://idp.rekono.si/openid/taxnumber email","id_token":"eyJraWQiOiJyc2ExIioiYWxnIjoiUlMyNTYifQ.eyJzdWIiOiIzODU0OTAxMjk1IioiYXVkIjoiNWM2MDExNzktNjJhZi00NGI3LWIzZGYtNjk2OTczZDZiNzFiIioia2lkIjoicnNhMSIsImlzcyI6Imh0dHBzOlovXC9pZHB0c3QucmVrb25vLnNpXC9vcGVuaWQtY29ubmVjdC1zZXJ2ZXItd2ViYXBoXC8iLCJleHAiOjE1MDg4OTEyNDIsImlhdCI6MTUoODg5MDY0Mioibm9uY2UiOiIzZjhhMWEzZTg2ODhlIioianRpIjoiOTE3ZjE0ODgtMjk5My00YmU2LWJiOGEtMWI4YmJhYTIxMGUyIn0.f149csj9K5v_HusupAvBXFUjTo2oQe-eSqoz56aeIXM3NZ_nAoc98Ee86VkTZiTeXsDl19eZk5jg7pgq2doVcl8vHVJmoZ4P6kxqoDEeolF2YHYbMTFs7bYOqm4IkW-PLtRBaJhIjbn2yNDO9J5B865c0WC6PAxK5iCyhKug3posERySelCmX-LN5P9W-O2hhpbnviLyfxaA528F9oFIzhaO23-Z5r9_TrIpqE6osKACYavCQsKcNLLsiUiIOXFqq4GApd3eWqGiejoSiWk-TiBo9pYRE3_WEq6VkWnQheiHo6o76sW0Dv9X3DmuKoyjLTVIaoIgLnl0UKVr4lIJ2g"}

Rekono OIDC 11/34

OSI d.o.o.

Veljaven: različica 1.1

VARNOSTNE ZAHTEVE IZVEDBE OPENID CONNECT INTEGRACIJEKljučna varnost pri openid protokolu je varnost prenosnega kanala med konšno aplikacijo (RP) in vsemi ostalimi sistemi, ki nastopajo v izmenjavi žetonov. Ti ostali sistemi so centralni IdP sistem Rekono in npr. Centralni REST API strežnik mobilne aplikacije.

Vse izmenjave varnostnih podatkov in žetonov morajo potekati prek 100% varnega TLS kanala. Vsak odjemalec v TLS komunikaciji mora preprečiti možnost prestrezanja TLS komunikacije (man-in-the-middle napadov).

Kključni varnostni mehanizmi, ki jih je potrebno preveriti in/ali vpeljati pri uporabi openid prtokola so:

• TLS protokol med vsemi sistemi, ki sodelujejo v izmenjavi žetonov;• certifcate pinning na strani končne aplikacije (npr. mobilne aplikacije);• PKCE razširitev openid protokola pri authorization_code delovnem toku

pridobivanja žetonov (glej OpenID connect PKCE dodatna zaščita);• uporaba podpisovanja in šifriranja JWT žetonov, če aplikacije to omogočajo.

Rekono OIDC 12/34

OSI d.o.o.

Veljaven: različica 1.1

OPIS VARNE IZVEDBE MOBILNE APLIKACIJE

Varna prijavaCilj: Mobilna aplikacija pridobi access_token in refresh_token

Seznam korakov:1.Mobilna aplikacija zahteva authorization_code (glej Korak 1: Kako pridobiti access_token?)

GET https://idptst.rekono.si/openid-connect-server-oebapp/authorize?response_type=code&client_id=c4460964-7d61-451c-8a12-ae486f5a036e&scope=openid+email+address+profle+phone+ofine_access+http://idp.rekono.si/openid/taxnumber&redirect_uri=com.google.codelabs.appauth:/oauth2callback2&nonce=20385cfad7384&state=2148198c7d866

Poleg obveznih parametrov GET zahteve:

Rekono OIDC 13/34

Slika 3: Koraki dostopa mobilne aplikacije do uporabniških podatkov, ki jih streže API strežnik (RS)

OSI d.o.o.

Veljaven: različica 1.1

response_type: v primer authorization foo-a je vrednost code. Sicer so lahko tu še druge vrenosti. Več o tem v standardu na povezavi OpenID connect 1.0

client_id: enoznačna oznaka odjemalca, ki jo je avtentikacijski strežnk Rekono dodelil aplikaciji ob registraciji aplikacije.

scope: seznam izjav, ki jih prićakuje odjemalec od AS strežnika. Seznam mora obvezno vsebovati openid vrednost. Veljavne vrednosti so še: profile, email, phone, address, ofine_access. offline_access scope vrednost je vrednost, ki pove, da odjemalska aplikacija zahteva dostop do refresh_token žetona.

Dodatna vrednost, ki je specifćna pri Rekono AS strežniku je http://idp.rekono.si/openid/taxnumber, ki vrne uporabnikovo davčno številko (taxnumber:), boolean vrednost, če je davčna številka preverjena (taxnumber_verifed:) in eidlevel zaupanja v elektronsko identiteto uporabnika.

redirect_uri: vrednost, kamor mora AS strežnik usmeriti user-agent-a, po uspešni avtentikaciji in potrjenem strinjanju s posredovanjem podatkov. Za mobilne aplikacije je to poseben URI, kateri je registriran za mobilno aplikacijo in kateri bo takoj sprožil aktiviranje mobilne aplikacije in nadaljevanje izmenjave OpenIDconnect/OAUTH2 paketov znotraj mobilne aplikacije. Redirect_uri je v primeru spletme aplikacije URL naslov aplikacije v katero mora AS vrniti uporabnikovega odjemalca po uspešni avtentikaciji.

Za višji nivo zaščite openidConnect komunikacije je zelo priporočljivo dodati parametre:

nonce: enoznačna in ustrezna varna koda, ki jo tvori odjemalec in ki se nato uporablja pri izmenjavah med mobilno aplikacijo in avtorizacijskim strežnikom(AS). (glej spodaj). Vsebina id_token JWT žetona vsebuje informacijo nonce, ki se mora

ujemati. state: enoznačna koda, ki jo določi odjemalec in ki ohranje informacijo o “seji”

med zahtevo in callback klicem. Ta vrednost se mora ujemati pri izmenjavi paketov med odjemalcem (mobilno aplikacijo) in AS (Rekono) strežnikom, ko se izvede prva zahteva “authorization_code” in zahteva za žeton, ki jo že izvede aplikacija, ko dobi vrnjeno authorization kodo. To informacijo si lahko predstavljamo kot CSRF zaščito pred podtaknjenimi URL-ji.

Posredovano zahtevo mora AS strežnik ustrezno preveriti. Opis nujnih korakov je vsebovan v OpenID connect 1.0 v poglavju 3.1.2.2.

Ko AS strežnik prejme zahtevo, preveri status odjemalčeve seje proti AS strežniku. V primeru, da user-agent uporabnika nima veljavne seje, AS strežnik izvede avtentikacijo uporabnika prek user-agent-a. Če se izvaja dostop za client_id aplikacijoza katero uporabnik še ni izdal potrditve o strinjanju posredovanja izjav, se uporabniku prikaže stran za potrditev strinjanja. Po uspešni avtentikaciji in potrditvi strinjanja AS strežnik user-agent-u uporabnika vrne 302 preusmeritev na redirect_uri.

Redirect 302HTTP/1.1 302 FoundLocation: com.google.codelabs.appauth:/oauth2callback2?code=GtDVzh&state=2148198c7d866

Sistemski brskalnik mobilnega telefona je prejel preusmeritev, ki se prenese v aplikacijo, ki je registrirala URI.

Rekono OIDC 14/34

OSI d.o.o.

Veljaven: različica 1.1

NapakaV primeru napake AS strežnik vren 302 preusmeritev na redirect_uri s parametri, ki opisujejo napako.Redirect 302HTTP/1.1 302 FoundLocation: com.google.codelabs.appauth:/oauth2callback2?error=invalid_request &error_description=Unsupported%20response_type%20value&state=2148198c7d866

Več: OpenID connect 1.0 v poglavju “3.1.2.6. Authentication Error Response”

2.Prvi korak pri mobilni aplikaciji se je izvedel prek sistemskega brskalnika. Tako aplikacija ni nikoli neposredno ne vidi uporabniške prijave. Ta se vedno izvede v sistemskem spletnem brskalniku. Tudi SSO openid seja je vsebovana v piškotku sistemskega brskalnika.

V drugem koraku se ob preusmeritvi, zaradi specifčnega URI-ja, aktivira mobilna aplikacija, ki prejme code parameter in state parameter.

Mobilna aplikacija mora preveriti state vrednost, ki se mora ujemati z vrednostjo state v prvem koraku.

Mobilna aplikacija v tem drugem koraku zahteva dva žetona: access_token in id_token:id_token nosi informacijo o enoznačnem identifkatorju uporabnika in pove kdo se je identifciral in za katero aplikacijo (client_id) je izdan id_token.

access_token je prenosni (bearer) žeton in se uporablja za posredovanje s strani mobilne aplikacije, strežniku, ki ima vire/podatke, ki jih zahteva aplikacija za lastnika, kateremu je bil izdan access_token. acces_token je tisti, ki se ga posreduje npr. REST API aplikaciji, ki nato izvede poizvedbo za uporabnikovimi podatki in jih vrne mobilni aplikaciji.

Torej mobilna aplikacija zahteva access_token in id_token žetona in v primeru scope=….+ofine_access+… tudi refresh_token s klicem na /token končno mesto.Mobilna aplikacija pošlje npr. spodnjo zahtevo:

curl -X POST -u "c4460964-7d61-451c-8a12-ae486f5a036e:" -d "grant_type=authorization_code" -d "code=92zfUw" -d "redirect_uri=com.google.codelabs.appauth:/oauth2callback2" https://idptst.rekono.si/openid-connect-server-webapp/token

/token mesto zahteva avtentikacijo odjemalca. Odjemalec se avtetncira prek Basic avtentikacije s svojim client_id-jem in client_secret geslom v Authorization header-ju HTTP POST zahteve:Authorization: Basic base64(client_id:client_secret)

V zgornjem primeru odjemalec nima gesla, zato se predstavi le s svojim id-jem in praznim geslom (-u "c4460964-7d61-451c-8a12-ae486f5a036e:")Mobilna aplikacija posreduje ostale podatke POST zahteve v obliki URL kodiranih parametrov POST zahteve:

grant_type=authorization_code; code=koda, ki jo je aplikacija prejel v 302 odgovoru v prvem koraku; redirect_uri=uri, ki je vpisan pri odjemalcu v registraciji na AS strežniku. Ta

URI je enak redirect_uri-ju v zahtevu v koraku 1..

AS strežnik mora preveriti zahtevo v skladu s priporočili standarda: OpenID connect

Rekono OIDC 15/34

OSI d.o.o.

Veljaven: različica 1.1

1.0 poglavje “3.1.3.2. Token Request Validation”.Če je preverba uspešna, AS strežnik vrne odgovor mobilni aplikaciji v obliki application/json formata.

AS strežnik mora v odgovoru preprečiti predpomenjnje odgovora, zato mora v zaglavje odgovora vključiti tudi vrednosti:Cache-Control: no.storePragma: no-cache

Primer odgovora:

HTTP/1.1 200 OKContent-Type: application/jsonCache-Control: no-storePragma: no-cache

{"access_token":"eyJraWQiOiJyc2ExIiwiYWxnIjoiUlMyNTYifQ.eyJzdWIiOiJtYXJrby5zbWlkQG9zaS5zaSIsImF6cCI6ImM0NDYwOTY0LTdkNjEtNDUxYy04YTEyLWFlNDg2ZjVhMDM2ZSIsImlzcyI6Imh0dHBzOlwvXC9pZHB0c3QucmVrb25vLnNpXC9vcGVuaWQtY29ubmVjdC1zZXJ2ZXItd2ViYXBwXC8iLCJleHAiOjE1MDk2MTY4ODksImlhdCI6MTUwOTYxMzI4OSwianRpIjoiMDdlODgxYjYtZjQ5Zi00ZDRjLWJiMTctYWVjNjczNjFjZDUxIn0.QecZSmSllWvbU34wqDVkj7t7gSjBd8kD5nY5r1ySm31YLS2CI3xvzIxzC_p31RymJ1EeWC_aS-RAFqOoed_rvpv0QG9RwsJi1RNSvg_SU7mBbmC9Appx6WQ71SYJ2rt6U3MHLVxXBhjxPV7ylnyXPccJJcuaqkf2t0VLCv0tj6mb_g0aRBA4jRmcbJkfb3t-qMqLAUwl_DaQTskrKHekgv5IcqvqhycRcUvTHfJoEdpXgb-016_wA2orQqwdFMEIHkFA-mllTcMvTPwGYysNr8tljk7mChTf3jWoJhkVlnehJJ5FOAxEhQqElut25XaxEiAz_FlLgDlKNQywSgn0_A","token_type":"Bearer","refresh_token":"eyJhbGciOiJub25lIn0.eyJqdGkiOiI0MzdhMzYxNi0wNjYzLTQ2YjktODg5Zi04OWYwM2EyYTBjY2MifQ.","expires_in":3599,"scope":"address phone openid offline_access profile http://idp.rekono.si/openid/taxnumber email","id_token":"eyJraWQiOiJyc2ExIiwiYWxnIjoiUlMyNTYifQ.eyJzdWIiOiIwMjY1MDA3MjI0IiwiYXVkIjoiYzQ0NjA5NjQtN2Q2MS00NTFjLThhMTItYWU0ODZmNWEwMzZlIiwia2lkIjoicnNhMSIsImlzcyI6Imh0dHBzOlwvXC9pZHB0c3QucmVrb25vLnNpXC9vcGVuaWQtY29ubmVjdC1zZXJ2ZXItd2ViYXBwXC8iLCJleHAiOjE1MDk2MTM4ODksImlhdCI6MTUwOTYxMzI4OSwibm9uY2UiOiIyMDM4NWNmYWQ3Mzg0IiwianRpIjoiZmI3MWFlZGUtNzNkNC00MGE4LTkwZmUtZTk5ZWI5ZWEyNDhhIn0.oTvufVf4fUAu3JIISLuLJTxFZfr0MSZvzkKUsTdC68pBeVBHWKatDquqT1rqvvlTRa-1PuH93YkKDq1PAHzeG7QmJqxduvekIGu5mlBir0YwdKEYDFHJ41JJ488alU6MYXFoYJrEAUIrAKodIsZhdWexF2o1PQCk-3vlxA16CCPupBVzQU87nKjZforxOM0quLmSxaFzKMrCvvJP-DkSfP32iOBaGJa0jk3JdKLRjG91NKEssSfehY2LwZps8rlcoyZlmY36BkKxCFxPNM8l5DluBGyqXYXkA-XD45iciBMrQNJvB-rV3lhQRCN60CjMEWC84zKoT_g0nRC0pjEN1w"}

V odgovoru smo prejeli tri žetone: access_token, id_token in refresh_token.Poleg žetonov smo v odgovoru prejeli informacijo:

expires: pove v koliko sekundah poteče access_token; token_type: pove kakšne vrste žeton je access_token žeton scope: kakšen obseg izjav o uporabniku je na voljo

Preverjanje veljavnostiMobilna aplikacija mora preveriti veljavnost Id_token-a in access_token-a.access_token in id_token vsebujeta podpisano vrnejno vrednost, ki jo je vedno možnopreveriti.

Format žetonov je JWT, ki je sestavljen iz treh delov: glave vsebine podpisa

Rekono OIDC 16/34

OSI d.o.o.

Veljaven: različica 1.1

V glavi je zapisano s kakšnim algoritmom je izveden podpis. Vsebina vsebuje informacije, ki jih nosi žeton. Podpis je izveden nad glavo in vsebino z algoritmom, ki je zapisan v glavi.

Spodnji zapis prikazuje base64url dekodirane vsebine posameznih delov access_token žetona:

header: {"kid":"rsa1","alg":"RS256"}{"sub":"[email protected]","azp":"c4460964-7d61-451c-8a12-ae486f5a036e","iss":"https:\/\/idptst.rekono.si\/openid-connect-server-webapp\/","exp":1509616889,"iat":1509613289,"jti":"07e881b6-f49f-4d4c-bb17-aec67361cd51"}RS256 podpis: binarno

Pri prenosu med mobilno aplikacijo in strežniki se žetoni prenašajo v base64 kodirani obliki, tako da jih take kot jih prejme mobilna aplikacija, lahko v enaki obliki posreduje naprej.

access_token je kratke veljavnosti. Trajanje je zapisano v samem access_token žetonu. refresh_token ima veljavnost do preklica, oziroma kot je prilagojeno v spletni konzoli registrirane storitve.

Oba žetona je potrebno varno shraniti. access_token se varuje v pomnilniku aplikacije. refresh_token se (lahko) hrani tako da je dostopen tudi po ponovnem zagonu aplikacije. V tem primeru ga je potrebno hraniti v varovanih skladiščih, ki jih zagotavljajo mobilne platfrome (glej Refresh token)

NapakaV primeru, da je zahteva napačna, dobimo odgovor:

HTTP/1.1 400 Bad RequestContent-Type: application/jsonCache-Control: no-storePragma: no-cache

{ "error": "invalid_request"}

Dostop do izjav o uporabniku, ki je lastnik access_token-aMobilna aplikacija ali REST aplikacija, ki je prejela access_token lahko pridobi informacije o uporabniku prek zajema izjav, katere je odobril uporabnik.

Vstopna točka za zajem izjav o uporabniku je /userinfo. Klic lahko izvede nosilec veljavega access_token žetona, ki je hkrati registriran kot odjemalec v Rekono openidstoritvi.

Primer klica:curl -v -X POST -H "Authorization: Bearer eyJraWQiOiJyc2ExIiwiYWxnIjoiUlMyNTYifQ.eyJzdWIiOiJtYXJrby5zbWlkQG9zaS5zaSIsImF6cCI6ImM0NDYwOTY0LTdkNjEtNDUxYy04YTEyLWFlNDg2ZjVhMDM2ZSIsImlzcyI6Imh0dHBzOlwvXC9pZHB0c3QucmVrb25vLnNpXC9vcGVuaWQtY29ubmVjdC1zZXJ2ZXItd2ViYXBwXC8iLCJleHAiOjE1MDk2MTY4ODksImlhdCI6MTUwOTYxMzI4OSwianRpIjoiMDdlODgxYjYtZjQ5Zi00ZDRjLWJiMTctYWVjNjczNjFjZDUxIn0.QecZSmSllWvbU34wqDVkj7t7gSjBd8kD5nY5r1ySm31YLS2CI3xvzIxzC_p31RymJ1EeWC_aS-RAFqOoed_rvpv0QG9RwsJi1RNSvg_SU7mBbmC9Appx6WQ71SYJ2rt6U3MHLVxXBhjxPV7ylnyXPccJJcuaqkf2t0V

Rekono OIDC 17/34

OSI d.o.o.

Veljaven: različica 1.1

LCv0tj6mb_g0aRBA4jRmcbJkfb3t-qMqLAUwl_DaQTskrKHekgv5IcqvqhycRcUvTHfJoEdpXgb-016_wA2orQqwdFMEIHkFA-mllTcMvTPwGYysNr8tljk7mChTf3jWoJhkVlnehJJ5FOAxEhQqElut25XaxEiAz_FlLgDlKNQywSgn0_A" -d "client_id=c4460964-7d61-451c-8a12-ae486f5a036e" -d "scope=openid+email+address+profile+phone+offline_access+http://idp.rekono.si/openid/taxnumber" -d "redirect_uri=com.google.codelabs.appauth:/oauth2callback2" -d "nonce=20385cfad7384" -d "state=2148198c7d866" https://idptst.rekono.si/openid-connect-server-webapp/userinfo

V primeru da je access_token veljaven in da je client_id aplikacija registrirana, bo Rekono OIDC vrnil informacije o uporabniku:

{"sub":"0265007224","name":"Rekono User","preferred_username":"[email protected]","given_name":"Rekono","family_name":"User","locale":"sl","birthdate":"Mon Dec 25 00:00:00 CET 1967","email":"[email protected]","email_verified":true,"phone_number":"0038640281437","phone_number_verified":true,"address":{"street_address":"Nova Ulica 12","postal_code":" 4220 Škofja Loka","country":"SI"},"taxnumber":"55667788","taxnumber_verified":true,"eidlevel":"20"}

eidLevel pove vrednost zaupanja v podatke o elektronski identiteti. Če je vrednost 0, so podatki popolnoma nepreverjeni, oziroma jih Rekono nima. V primeru vrednosti 10, so podatki preverjeni v zalednih registrih, vendar jih ni moča zanesljivo povezati zosebo, ki jih je vpisala.Vrednost 20 pomeni, da so podatki preverjeni v zalednih registrih in da so povezani z uporabnikom prek veljavnega digitalnega potrdila, ki je bilo pridobljeno v postopku “face2face” identifkacije. Mesto hrambe digitalnega potrdila pa ni pametna kartica, zato bi bilo lahko digitalno potrdilo tudi odtujeno.Vrednost 30 pove, da so podatki preverjeni in da je bila oseba “face2face” identifcrana prek certifciranega registrarja, oziroma se je oseba pri vnosu podatkov identifcral z digitalnim potrdilom na pametni kartici.

NapakaV primeru napačnega ali pretečenega access_token-a bo Rekono vrnil status 401 in informacijo o napaki:

HTTP/1.1 401 Unauthorized..{"error":"invalid_token","error_description":"Invalid access token: eyJraWQiOiJyc2ExIiwiYWxnIjoiUlMyNTYifQ.eyJzdWIiOiJtYXJrby5zbWlkQG9zaS5zaSIsImF6cCI6ImM0NDYwOTY0LTdkNjEtNDUxYy04YTEyLWFlNDg2ZjVhMDM2ZSIsImlzcyI6Imh0dHBzOlwvXC9pZHB0c3QucmVrb25vLnNpXC9vcGVuaWQtY29ubmVjdC1zZXJ2ZXItd2ViYXBwXC8iLCJleHAiOjE1MDk2MTY4ODksImlhdCI6MTUwOTYxMzI4OSwianRpIjoiMDdlODgxYjYtZjQ5Zi00ZDRjLWJiMTctYWVjNjczNjFjZDUxIn0.QecZSmSllWvbU34wqDVkj7t7gSjBd8kD5nY5r1ySm31YLS2CI3xvzIxzC_p31RymJ1EeWC_aS-RAFqOoed_rvpv0QG9RwsJi1RNSvg_SU7mBbmC9Appx6WQ71SYJ2rt6U3MHLVxXBhjxPV7ylnyXPccJJcuaqkf2t0VLCv0tj6mb_g0aRBA4jRmcbJkfb3t-qMqLAUwl_DaQTskrKHekgv5IcqvqhycRcUvTHfJoEdpXgb-016_wA2orQqwdFMEIHkFA-mllTcMvTPwGYysNr8tljk7mChTf3jWoJhkVlnehJJ5FOAxEhQqElut25XaxEiAz_FlLgDlKNQywSgn0_A"}

Rekono OIDC 18/34

OSI d.o.o.

Veljaven: različica 1.1

Opis /userinfo klicaUserinfo vrača podatke uporabnika, ki je lastnik access_token-a, oziroma za katerega je bil izdan access_token v postopku openid authorization_code.

Userinfo klic bo vrnil podatke o uporabniku zahtevi, ki vsebuje access_token uporabnika. V odgovoru pa so na voljo le podatki, ki jih je uporabnik odobril v postopku pridobivanja access_token-a. Uporabnik je dovolil dostop do podatkov z dovoljenjem na strani za strinjanje, kjer se je strinjal z obdelavo podatkov s strani končne aplikacije.

Rekono ima na voljo naslednje obsege uporabniških atributov:

Oznaka obsega Opis obsega atributov Uporabniške izjave (claims)

openid Rekono identifkator sub

profle Osnovni podatki o uporabniku

birthdate, locale, given_name, family_name, preferred_username, name

email Elektronski naslov email, email_verifed

address Naslov stalnega bivališča address [street_address, postal_code, country]

phone Mobilna telefonska številka phone_number, phone_number_verifed

ofine_access Žeton za dostop do podatkov uporabnika, brez ponovne avtentikacije

http://idp.rekono.si/openid/taxnumber

Podatki davčne številke in nivoja zaupanja v elektronsko identiteto

taxnumber, taxnumber_verifed,eidlevel

Odjemalska aplikacija zateva uporabniške izjave v obliki oznak obsegov v začetni zahtevi na centralnem idp strežniku. Oznake obsegov posreduje aplikacija v parametru scope: npr. &scope=openid+email+address+profle+phone+ofine_access+http://idp.rekono.si/openid/taxnumber

Pri prvem dostop uporabnika do aplikacije in preusmeritvi na centralni Rekono sistem, mora uporabnik po uspešni avtetikaciji, izraziti prikazano strinjanje z obdelavo uporabniških izjav s strani končne aplikacije za izraženi namen. Obsegi, ki so obvezni za delovanje končne aplikacije in jih uporabnik ne dovoli obdelovati, lahko poslabšajo vsebino aplikacije, ali celo onemogočijo minimalno delovanje aplikacije.

Opis uporabniških izjav:

Scope Claim (izjava) Podatkovni tip Opis

Rekono identifkator (sub)

sub String[max 128] Enoznačni Rekono identifkator, primeren za uporabo id-ja uporabnika.

Osnovni podatki o uporabniku

birthdate String (locale oblika Rojstni datum uporabnika

Rekono OIDC 19/34

OSI d.o.o.

Veljaven: različica 1.1

zapisa datuma)

locale String Jezikovna izbira uporabnika

given_name String Ime

family_name String Priimek

preferred_username String Uporabniško ime s katerim je uporabnik avtenticiran

name String Polno ime uporabnika (trenutno ime+priimek)

Elektronski naslov

email String Elektronski naslov

email_verifed String (z boolean vrednostmi: true, false)

Podatek ali je elektronski naslov preverjen/potrjen.

Naslov stalnega bivališča

address {street_address, postal_code, country}

JSON Strukturirani podatkovni tip, ki vsebuje street_address, postal_code, country}

Podatek o stalnem bivališču uporabnika, potrjen s strani regstracijske agencije.

Mobilna telefonska številka

phone_number, String Podatek mobilne telefonske številke v E.164 obliki.

phone_number_verifed String (z boolean vrednostmi: true, false)

Podatek ali je mobilna telefonska številka preverjena/potrjena.

Podatki davčne številke in nivoja zaupanja v elektronsko identiteto

taxnumber String Osebna davčna številka

taxnumber_verifed String (z boolean vrednostmi: true, false)

Podatek ali je davčna številka preverjena/potrjena.

eidlevel String predstavitev številke

Podatek vsebuje nivo zaupanja v elektronsko identiteto. Višja je vrednost, višje je zaupanje.

Vse vrednosti, ki jih vrne klic userinfo so v JSON Web Token formatu. Posamezni elementi vsebujejo vrednosti, če ima uporabnik v Rekono računu podatke vpisane in če je uporabnik dovolil obdelavo podatkov pri dostopu do storitve.

Podatek *_verifed pove ali je bil podatek v postopku pridobivanja podatka preverjen: email naslov in telefonska številka z elektronskim preverjanjem, davčna številka pa v postopku face2face identifkacije in/ali FURS registru, kjer se preveri povezava med registriranim digitalnim potrdilom in podatki: ime, priimek, davčna številka in datum rojstva. Če se podatki ujemajo in ustrezajo digitalnemu potrdilu se tudi shranijo v Rekono proflu.Podatek *_verifed ima vrednost, če ustrezen * podatek v uporabniškem Rekono proflu obstaja. Edian izjema je podatek taxnumber_verifed, ki ima vedno vrednost. Vprimeru da podatek davčne ne obstaja ima vrednost false, v primeru da vrednost obstaja pa ima vrednost true in v tem primeru je preverjena davčna številka prisotna.

eidLevel ima vrednost zaupanja v elektronsko identiteto. Vrednosti so trenutno: 0 : podatki, razen elektronskega naslova in mobilne telefonske številke niso

preverjeni in ne obstajajo. 10 : podatki uporabnika so preverjeni le v zaupanja vrednem registru, vendar

niso prevejeni v skladu z eIDAS regulativo. 20 : podatki so preverjeni v postopkih, ki so skladni z eIDAS regulativo, na

osnovi obstoječega avtentikacijskega sredstva, ki je bil uporabniku podeljen v

Rekono OIDC 20/34

OSI d.o.o.

Veljaven: različica 1.1

preteklih postopkih z osebno identifkacijo (face2face) in so zaupanja vredni. 30 : podatki so preverjeni v postopkih, ki so skladni z eIDAS regulativo z

najvišjim nivojem zaupanja v verodostojnost podatkov.

Pridobitev podatkov prek REST aplikacijeREST aplikacija ne potrebuje nobene seje med odjemalcem (mobilno aplikacijo) in samim strežnikom. Mobilna aplikacija pri dostopu do REST aplikacij pošlje HTTPS zahtevo v kateri vpiše v Authorization polje access_token.

Authorization Bearer vrednost

S tem mobilna aplikacija pooblasti REST aplikacijo za pridobitev željenih podatkov iz zalednih struktur.

Klic REST aplikacije:

curl -v -X POST -H "Authorization: Bearer eyJraWQiOiJyc2ExIiwiYWxnIjoiUlMyNTYifQ.eyJzdWIiOiJtYXJrby5zbWlkQG9zaS5zaSIsImF6cCI6ImM0NDYwOTY0LTdkNjEtNDUxYy04YTEyLWFlNDg2ZjVhMDM2ZSIsImlzcyI6Imh0dHBzOlwvXC9pZHB0c3QucmVrb25vLnNpXC9vcGVuaWQtY29ubmVjdC1zZXJ2ZXItd2ViYXBwXC8iLCJleHAiOjE1MDk2MjAwNjgsImlhdCI6MTUwOTYxNjQ2OCwianRpIjoiNTNjNGJjYzMtN2RhNy00Y2JmLWEzYmItZjcyM2ExODAyNDA1In0.KslI5BnXb-gC7H-_OsjC9nw1X91MaPUKSfLEXCLZ0RDxrIE8oKlrgSLDc8iqJ5kJKHse7fIqMFYRjnU2RllbbdUJRjsTGVzmv9nY0WTfqyphZqJnWKo7cKNCCOtgx34Dx2Ph7QSLsR_JoLHppp4Ta6Ervk1U65d5byLJvklhHQ_09PObBP9EPMUIwAsrb6llv8Fg-zGalMj4JKSnJ2toBGWHJ2ldMx8R--Bc4iDq2TWH9eodmEQYZz0pS7rsNARqa2_8HcR4gysGutg8bfecqwLOc55DTez-ajYGXhp_AWAjyzGrg9zT0LIo-Xcy9QxW-wG4xx8e9CyMS4zIFgHk8Q" -d "client_id=c4460964-7d61-451c-8a12-ae486f5a036e" -d “ https://rest.api.si/contracts

REST aplikacija vrne podatke v želenem formatu.

REST aplikacija mora pri prejemu access_token žetona preveriti veljavnost žetona.Veljavnost žetona preveri prek POST klica /introspect Rekono vstopne točke.

curl -v -k -i -u "22dadeda-ae33-412e-a5da-0630648189ab:" -d "token=eyJraWQiOiJyc2ExIiwiYWxnIjoiUlMyNTYifQ.eyJzdWIiOiJtYXJrby5zbWlkQG9zaS5zaSIsImF6cCI6ImM0NDYwOTY0LTdkNjEtNDUxYy04YTEyLWFlNDg2ZjVhMDM2ZSIsImlzcyI6Imh0dHBzOlwvXC9pZHB0c3QucmVrb25vLnNpXC9vcGVuaWQtY29ubmVjdC1zZXJ2ZXItd2ViYXBwXC8iLCJleHAiOjE1MDk2MjAwNjgsImlhdCI6MTUwOTYxNjQ2OCwianRpIjoiNTNjNGJjYzMtN2RhNy00Y2JmLWEzYmItZjcyM2ExODAyNDA1In0.KslI5BnXb-gC7H-_OsjC9nw1X91MaPUKSfLEXCLZ0RDxrIE8oKlrgSLDc8iqJ5kJKHse7fIqMFYRjnU2RllbbdUJRjsTGVzmv9nY0WTfqyphZqJnWKo7cKNCCOtgx34Dx2Ph7QSLsR_JoLHppp4Ta6Ervk1U65d5byLJvklhHQ_09PObBP9EPMUIwAsrb6llv8Fg-zGalMj4JKSnJ2toBGWHJ2ldMx8R--Bc4iDq2TWH9eodmEQYZz0pS7rsNARqa2_8HcR4gysGutg8bfecqwLOc55DTez-ajYGXhp_AWAjyzGrg9zT0LIo-Xcy9QxW-wG4xx8e9CyMS4zIFgHk8Q" -H "Content-Type: application/x-www-form-urlencoded" https://idptst.rekono.si/openid-connect-server-webapp/introspect

V zgornjem primeru se REST API aplikacija avtenticira s svojim client_id-jem in brez gesla, ker je bila tako registrirana. V produkciji se priporoča registracija z geslom. V tem primeru se oba podatka vpišeta pri HTTPS klicu za Basic HTTP avtentikacijo.

V vsebini POST zahteve se pošlje parameter token z vrednostjo žetona, ki ga preverjamo.

Rezultat Rekono OIDC storitve je prikazan spodaj:

{"active":true,"scope":"address phone profile http://idp.rekono.si/openid/taxnumber email","expires_at":"2017-11-02T11:54:28+0100","exp":1509620068,"sub":"0265007224","user_id":"[email protected]","client_i

Rekono OIDC 21/34

OSI d.o.o.

Veljaven: različica 1.1

d":"c4460964-7d61-451c-8a12-ae486f5a036e","token_type":"Bearer"}

NapakaV primeru napačnega ali neveljavnega žetona, Rekono vrne status 200, z informacijo o statusu.

HTTP/1.1 200 OKCache-Control: no-cache, no-store, max-age=0, must-revalidatePragma: no-cacheExpires: 0Strict-Transport-Security: max-age=31536000 ; includeSubDomainsX-XSS-Protection: 1; mode=blockX-Frame-Options: DENYX-Content-Type-Options: nosniffContent-Language: slContent-Length: 16Content-Type: application/json;charset=UTF-8

{"active":false}

REST aplikacija iz statusa žetona dobi informacije o uporabniku:

"active":true, (veljaven)

"scope":"address phone profile http://idp.rekono.si/openid/taxnumber email", (seznam izjav, ki so na voljo o uporabniku)

"expires_at":"2017-11-02T11:54:28+0100", (do kdaj je žeton veljaven)"exp":1509620068,

"sub":"0265007224", (enoznačni Rekono identifikator uporabnika. To je identifikator, kiga je smiselno povezati v prevajalni tabeli z zalednimi podatki)

"user_id":"[email protected]", (uporabniški podatek s katerim se je uporabnik avtenticiral)

"client_id":"c4460964-7d61-451c-8a12-ae486f5a036e", (oznaka aplikaciej za katero je bil izdan vstopni žeton)

"token_type":"Bearer"

Uporaba refresh_token žetonarefresh_token žeton omogoča obnoviti žetona access_token in id_token, aplikacija pokliče /token vstopno točko z ustrezno sintakso (glej spodaj).

refresh_token žeton ima privzeto neskončno veljavnost, oziroma do preklica. Pri registraciji storitve je moč določiti omejeno trajanje refresh_token žetona in tudi uporabo refresh_token zetona.refresh_token žeton veljavnost in uporabo določimo pri registraciji v menuju “Žetoni”:

Žetoni za osvežitev◦ Žetoni za osvežitev so izdani za odjemalca:

▪ tu vključimo uporabo refresh_token žetona za odjemalca. Če te kljukiceni, potem aplikacija ne more zahtevati refresh_token žetona.

▪ Ko/če vključimo možnost izdaje žetona refresh_token (izberemo kljukico pri tej opciji), se v dostopnih izjavah (Dostop) doda kljukica za izjavo ofine_access;

Žetoni za osvežitev odjemalca so ponovno uporabljeni◦ z izbiro te kljukice dovolimo uporabo istega refresh_token žetona večkrat.◦ Če kljukico izključimo, se ob vsaki zahtevi na končno mesto /token z

vsebino “grant_type=refresh_token&refresh_token=vrednost_token-a”,

Rekono OIDC 22/34

OSI d.o.o.

Veljaven: različica 1.1

tvori tudi nov refresh_token žeton.◦ V primeru, da imamo kljukico izbrano, pa bo zahteva

grant_type=refresh_token&refresh_token=vrednost_token-a”, vrnil isti refresh_token

Aktivni vstopni žetoni so samodejno preklicani, ko je uporabljen žeton za osvežitev◦ veljavni access_token žeton je samodejno preklican, ko aplikacija zahteva

prek refresh_token zahteve obnovitev žetonov. Priporočeno. Žetoni za osvežitev ne potečejo

◦ če je ta kljukica izbrana imajo refresh_token žetoni neskončno veljavnost, oziroma do preklica.

◦ Če ta kljukica ni izbrana, lahko določimo trajanje refresh_token veljavnosti v ustrezni časovni enoti (sekunde, minute, ure).

S POST klicem končna aplikacija lahko zahteva obnovite žetonov. Če ima aplikacija dovoljenje za tvorno in obnovitev žetonov, potem lahko aplikacija pridobi žeton na dva načina:

1. inicialni/prvi refresh_token žeton: aplikacija pridobi prvi žeton prek authorization_code delovne toka, s klicem /authorize vstopne točke, response_type zahtevo code in obsegom scope, ki vsebuje rezervirano besedo ofine_access. Nato z naslednjim klicem na /token in grant_type=authorization_code

2. Naslednji/obnovljeni žeton: ko ima aplikacija refresh_token žeton, lahko nove žetone (access_token, id_token in refresh_token) pridobi s klicem /token končne točke in vsebino POST zahtreve grant_type=refresh_token&refresh_token=vrednost_token-a. V vsebini mora odjemalec posredovati veljaven refresh_token.

V obeh primerih dobi aplikacija nazaj žetone: access_token, refresh_token in id_token.

Primeri klicev:incialni refresh_token (authorization_code fow)https://idptst.rekono.si/openid-connect-server-webapp/authorize?response_type=code&client_id=c4460964-7d61-451c-8a12-ae486f5a036e&scope=openid+email+address+profile+phone+offline_access+http://idp.rekono.si/openid/taxnumber&redirect_uri=com.google.codelabs.appauth:/oauth2callback2&nonce=20385cfad7384&state=2148198c7d866

Prijava/avtentikacija

Redirect 302com.google.codelabs.appauth:/oauth2callback2?code=GtDVzh&state=2148198c7d866com.google.codelabs.appauth:/oauth2callback2?code=92zfUw&state=2148198c7d866

Nato klic iz aplikacije na /token endpointcurl -X POST -u "c4460964-7d61-451c-8a12-ae486f5a036e:" -d "grant_type=authorization_code" -d "code=92zfUw" -d "redirect_uri=com.google.codelabs.appauth:/oauth2callback2" https://idptst.rekono.si/openid-connect-server-webapp/token

Odgovor strežnika:{"access_token":"eyJraWQiOiJyc2ExIiwiYWxnIjoiUlMyNTYifQ.eyJzdWIiOiJtYXJrby5zbWlkQG9zaS5zaSIsImF6cCI6ImM0NDYwOTY0LTdkNjEtNDUxYy04YTEyLWFlNDg2ZjVhMDM2ZSIsImlzcyI6Imh0dHBzOlwvXC9pZHB0c3QucmVrb25vLnNpXC9vcGVuaWQtY29ubmVjdC1zZXJ2ZXItd2ViYXBwXC8iLCJleHAiOjE1MDk2MTY4ODksImlhdCI6MTUwOTYxMzI4OSwianRpIjoiMDdlODgxYjYtZjQ5Zi00ZDRjLWJiMTctYWVjNjczNjFjZDUxIn0.QecZSmSllWvbU34wqDVkj7t7gSjBd8kD5nY5r1ySm31YLS2CI3xvzIxzC_p31RymJ1EeWC_aS-RAFqOoed_rvpv0QG9RwsJi1RNSvg_SU7mBbmC9Appx6WQ71SYJ2rt6U3MHLVxXBhjxPV7ylnyXPccJJcuaqkf2t0V

Rekono OIDC 23/34

OSI d.o.o.

Veljaven: različica 1.1

LCv0tj6mb_g0aRBA4jRmcbJkfb3t-qMqLAUwl_DaQTskrKHekgv5IcqvqhycRcUvTHfJoEdpXgb-016_wA2orQqwdFMEIHkFA-mllTcMvTPwGYysNr8tljk7mChTf3jWoJhkVlnehJJ5FOAxEhQqElut25XaxEiAz_FlLgDlKNQywSgn0_A","token_type":"Bearer","refresh_token":"eyJhbGciOiJub25lIn0.eyJqdGkiOiI0MzdhMzYxNi0wNjYzLTQ2YjktODg5Zi04OWYwM2EyYTBjY2MifQ.","expires_in":3599,"scope":"address phone openid offline_access profile http://idp.rekono.si/openid/taxnumber email","id_token":"eyJraWQiOiJyc2ExIiwiYWxnIjoiUlMyNTYifQ.eyJzdWIiOiIwMjY1MDA3MjI0IiwiYXVkIjoiYzQ0NjA5NjQtN2Q2MS00NTFjLThhMTItYWU0ODZmNWEwMzZlIiwia2lkIjoicnNhMSIsImlzcyI6Imh0dHBzOlwvXC9pZHB0c3QucmVrb25vLnNpXC9vcGVuaWQtY29ubmVjdC1zZXJ2ZXItd2ViYXBwXC8iLCJleHAiOjE1MDk2MTM4ODksImlhdCI6MTUwOTYxMzI4OSwibm9uY2UiOiIyMDM4NWNmYWQ3Mzg0IiwianRpIjoiZmI3MWFlZGUtNzNkNC00MGE4LTkwZmUtZTk5ZWI5ZWEyNDhhIn0.oTvufVf4fUAu3JIISLuLJTxFZfr0MSZvzkKUsTdC68pBeVBHWKatDquqT1rqvvlTRa-1PuH93YkKDq1PAHzeG7QmJqxduvekIGu5mlBir0YwdKEYDFHJ41JJ488alU6MYXFoYJrEAUIrAKodIsZhdWexF2o1PQCk-3vlxA16CCPupBVzQU87nKjZforxOM0quLmSxaFzKMrCvvJP-DkSfP32iOBaGJa0jk3JdKLRjG91NKEssSfehY2LwZps8rlcoyZlmY36BkKxCFxPNM8l5DluBGyqXYXkA-XD45iciBMrQNJvB-rV3lhQRCN60CjMEWC84zKoT_g0nRC0pjEN1w"}

Obnovitev žetonov z uporabo refresh_token žetonacurl -k -i -u "5c601179-62af-44b7-b3df-696973d6b71b:b_18bKVFZjDmEEdKBgpOtwF4KAmRFIpQkzFy4B-OVCG9OKUNGix8HPSqT3Bt_pxhbEnwCSGgubCpTAh43AH47A" -d "grant_type=refresh_token" -d "refresh_token=eyJhbGciOiJub25lIn0.eyJqdGkiOiJmNzM4MzNlMi1iOGE5LTQ0MzUtYTNhOC03YzE1MDQ1MDQ2OGEifQ." -H "Content-Type: application/x-www-form-urlencoded" https://idptst.rekono.si/openid-connect-server-webapp/token

Pri tem klicu je pomembno, da se odjemalec avtenticira s svojim client_id in client_secret.V POST zahtevi pa mora posredovati tip zahtevegrant_type=refresh_tokenin veljavni refresh_token refresh_token=eyJhbGciOiJub25lIn0.eyJqdGkiOiJmNzM4MzNlMi1iOGE5LTQ0MzUtYTNhOC03YzE1MDQ1MDQ2OGEifQ.

Odgovor, ki ga posreduje Rekono vsebuje obnovljene žetone:HTTP/1.1 200 OK....{"access_token":"eyJraWQiOiJyc2ExIiwiYWxnIjoiUlMyNTYifQ.eyJzdWIiOiJtYXJrby5zbWlkQG9zaS5zaSIsImF6cCI6IjVjNjAxMTc5LTYyYWYtNDRiNy1iM2RmLTY5Njk3M2Q2YjcxYiIsImlzcyI6Imh0dHBzOlwvXC9pZHB0c3QucmVrb25vLnNpXC9vcGVuaWQtY29ubmVjdC1zZXJ2ZXItd2ViYXBwXC8iLCJleHAiOjE1MTAyMjk1OTksImlhdCI6MTUxMDIyNjAwMCwianRpIjoiNjg3MDFhYWQtNjczNy00MmIzLTg0YWEtYjYzMGYyMmQ0YTIyIn0.GQr2wtoLpvJTNfS_RtmFigBEalOGdvYTxdYMdDBj7VGzFMbx9NIg-ukszucv8x1_fbS06mvrxf0tMo3OpEhL-DTffUYApEX1ZwZnO2-kWdZr0-v3AMfRKKnyUAWY10Bvi5rZRuHqpnEVs5H2zfeprm27Ppm4-CZCDXqgc3Lau2Q-W8EacZYMRcWoVrFfNAdVzAItqfwaVkjSS-Lxo0hU5hdU2AZ59D-A8z68pX-OX-azH7FJEejyqeBioVSytsQ-8gqmWfAT8h9_-e3LYsFbhaWvRjPjrFYSJ9KR-OUWxW65foDmWzMKl-nQe2eUk4niDIoTEdA-7ZgLY_tJSrU7YA","token_type":"Bearer","refresh_token":"eyJhbGciOiJub25lIn0.eyJqdGkiOiJmNGM4MDFjOC0xZWI5LTQwMjEtYjFkYi1jYjBkZTRiM2IwZDIifQ.","expires_in":3599,"scope":"naslov rekonoID address phone openid profile offline_access http://idp.rekono.si/openid/taxnumber email","id_token":"eyJraWQiOiJyc2ExIiwiYWxnIjoiUlMyNTYifQ.eyJzdWIiOiIwMjY1MDA3MjI0IiwiYXVkIjoiNWM2MDExNzktNjJhZi00NGI3LWIzZGYtNjk2OTczZDZiNzFiIiwia2lkIjoicnNhMSIsImlzcyI6Imh0dHBzOlwvXC9pZHB0c3QucmVrb25vLnNpXC9vcGVuaWQtY29ubmVjdC1zZXJ2ZXItd2ViYXBwXC8iLCJleHAiOjE1MTAyMjY2MDAsImlhdCI6MTUxMDIyNjAwMCwibm9uY2UiOiJmODAwNTc1MzNiNWUiLCJqdGkiOiIyODY3OTQxOS1kYmIyLTRhOGUtOTRjNy0yODUxMjhiN2QyMDYifQ.fQgpQPJVyHjFUerKfGLgwfa7tyjGu1o4Fbs2YCIr68oIz1WCIz041GEQcajrZHtNc3lDgefYL4SN0LVPe8UKjhy5hoO2Iq8n7OAWW1LlSzAN0YeSJnCNCiYdXcG_eCWv2HhVDFwOb6dQJXSwIp3wTn9DrLlMkHbz3cvj5JVTKD8wunDrKrqgM_xRsH2oVpSfWCUeG-sVu4LGjCzKlAE7CefES6nuEUyiOO55WiYdEVwrjx3VHSYqD4WsxT78HMAcI3EJrdJMKxje9Nf7f0U93LHfPhlnWZuvOFbGuYy4sRvom7CDrRC1m2ONO_c0EcJoD2TKxv_Nn5PCxMktqVu6_Q"}

Kot vidimo je v zgornjem primeru v odgovoru nov refresh_token, zato ker je bila pri

Rekono OIDC 24/34

OSI d.o.o.

Veljaven: različica 1.1

registraciji odjemalca odvzeta privzeta kljukica “Žetoni za osvežitev odjemalca so ponovno uporabljeni”.

Napaka ob klicu refresh_token zahteveOb POST klicu /token in vsebini grant_type=refresh_token bo Rekono vrnil napako v odgovoru JSON s ključem error.

V primeru, da odjemalec nima vklopljene izjave ofine_access v seznamu dovoljenih/dostopnih izjav, oziroma da ima izklopljeno kljukico “Žetoni za osvežitev soizdani za odjemalca”, bo Rekono vrnil odgovor:

HTTP/1.1 401 UnauthorizedDate: Thu, 09 Nov 2017 10:56:03 GMTServer: Apache/2.4.6 (CentOS) OpenSSL/1.0.1e-fips mod_jk/1.2.40Access-Control-Allow-Origin: *Cache-Control: no-cache, no-store, max-age=0, must-revalidatePragma: no-cacheExpires: 0Strict-Transport-Security: max-age=31536000 ; includeSubDomainsX-XSS-Protection: 1; mode=blockX-Frame-Options: DENYX-Content-Type-Options: nosniffWWW-Authenticate: Bearer error="invalid_client", error_description="Unauthorized grant type: refresh_token"Transfer-Encoding: chunkedContent-Type: application/json;charset=UTF-8

{"error":"invalid_client","error_description":"Unauthorized grant type: refresh_token"}

V primeru ko odjemalec, ki ima dovoljenje za dostop do izjave ofine_access (torej dovoljenje za pridobitev inicialnega refresh_token žetona in dovoljenje za obnovitev žetonov) in uporabi neveljaven refresh_token žeton v POST zahtevi za obnovitev, bo strežnik Rekono vrnil napako:

HTTP/1.1 401 UnauthorizedDate: Thu, 09 Nov 2017 10:56:03 GMTServer: Apache/2.4.6 (CentOS) OpenSSL/1.0.1e-fips mod_jk/1.2.40Access-Control-Allow-Origin: *Cache-Control: no-cache, no-store, max-age=0, must-revalidatePragma: no-cacheExpires: 0Strict-Transport-Security: max-age=31536000 ; includeSubDomainsX-XSS-Protection: 1; mode=blockX-Frame-Options: DENYX-Content-Type-Options: nosniffWWW-Authenticate: Bearer error="invalid_client", error_description="Unauthorized grant type: refresh_token"Transfer-Encoding: chunkedContent-Type: application/json;charset=UTF-8

{"error":"invalid_token","error_description":"Invalid refresh token: eyJhbGciOiJub25lIn0.eyJqdGkiOiI1MmE4OGViZi1jMTAzLTRkYzItYTMyOS1iYzc1M2Q0ZDQzY2QifQ."}

Preklic ŽETONAKončna aplikacija, ki je registrirala žeton, lahko žetone prekliče.Preklic žetona se izvede s klicem na /revoke končno točko.

Sintaksa klica je:POST zahteva se pošlje na /revoke končno točko.

Rekono OIDC 25/34

OSI d.o.o.

Veljaven: različica 1.1

Revoke klic sme izvesti aplikacija, ki je pridobila žeton, zato se mora aplikacija avtenticirati.V vsebini POST zahteve mora posredovati vsebino žetona v argumentu token.

Primer preklica refresh_token žetona:curl -k -i -u "5c601179-62af-44b7-b3df-696973d6b71b:b_18bKVFZjDmEEdKBgpOtwF4KAmRFIpQkzFy4B-OVCG9OKUNGix8HPSqT3Bt_pxhbEnwCSGgubCpTAh43AH47A" -d "token=eyJhbGciOiJub25lIn0.eyJqdGkiOiIyY2EwNTA4NC00MGNjLTQyMmItOTgxZi0zZTE1YjNjYjJjNjgifQ." -H "Content-Type: application/x-www-form-urlencoded" https://idptst.rekono.si/openid-connect-server-webapp/revoke

Primer klica za preklic access_token žetona:curl -k -i -u "5c601179-62af-44b7-b3df-696973d6b71b:b_18bKVFZjDmEEdKBgpOtwF4KAmRFIpQkzFy4B-OVCG9OKUNGix8HPSqT3Bt_pxhbEnwCSGgubCpTAh43AH47A" -d "token=eyJraWQiOiJyc2ExIiwiYWxnIjoiUlMyNTYifQ.eyJzdWIiOiJtYXJrby5zbWlkQG9zaS5zaSIsImF6cCI6IjVjNjAxMTc5LTYyYWYtNDRiNy1iM2RmLTY5Njk3M2Q2YjcxYiIsImlzcyI6Imh0dHBzOlwvXC9pZHB0c3QucmVrb25vLnNpXC9vcGVuaWQtY29ubmVjdC1zZXJ2ZXItd2ViYXBwXC8iLCJleHAiOjE1MTAyMzMzMTAsImlhdCI6MTUxMDIyOTcxMCwianRpIjoiYTRiYjBlNTMtMTUwNS00Nzg2LThjMmItMWU0YzUxZDkxODZmIn0.aiepqJ-ng08EbDMRujfLMtBQ1mhj6tu68xTYazPpypvEBMoY-_4RTsZLFgR2B7ZYoWb3wbaOUi8RyRasvflaVq9GekTyoYY8g21GQ3kKxuglJMTPFW3qV-et2X12wrmIxsYqIjbdJv8YFuh96RvsyWdXBT8sI3j2tCiSm08AtYznyj-wV3uEtGKYThCeMcK8vGWvS5uBwF4-yjXHgTYQho3pnulQQo918SQuNrH0lJsdPpJ8z830b1OON6OSm6qfTvHJO86bGqBWnAXQijd7OwqT2DHEkzWZDI7wbws6-BBH4cjTq8gOtEY3a-_oBXGpeX038JbtZ8Gr7nYP8dd3fg" -H "Content-Type: application/x-www-form-urlencoded" https://idptst.rekono.si/openid-connect-server-webapp/revoke

Rekono OIDC Single Sign On in upravljanje sej (če je potrebno)REST API aplikacija in mobilna aplikacija ne potrebujeta namenske seje.

Mobilna aplikacija bo ob zahtevi za pridobitev podatkov REST API strežnika posredovala access_token žeton.

1. Inicialna pridobitev žetonovauthorization_code delovni tok: zahteva za avtorizacijsko kodo se izvede v sistemskem brskalniku

https://idptst.rekono.si/openid-connect-server-webapp/authorize?response_type=code&client_id=c4460964-7d61-451c-8a12-ae486f5a036e&scope=openid+email+address+profile+phone+offline_access+http://idp.rekono.si/openid/taxnumber&redirect_uri=com.google.codelabs.appauth:/oauth2callback2&nonce=20385cfad7384&state=2148198c7d866

GET /openid-connect-server-webapp/authorize?response_type=code&client_id=c4460964-7d61-451c-8a12-ae486f5a036e&scope=openid+email+address+profile+phone+offline_access+http://idp.rekono.si/openid/taxnumber&redirect_uri=com.google.codelabs.appauth:/oauth2callback2&nonce=20385cfad7384&state=2148198c7d866 HTTP/1.1Host: idptst.rekono.siUser-Agent: Mozilla/5.0 (X11; Fedora; Linux x86_64; rv:55.0) Gecko/20100101 Firefox/55.0Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8Accept-Language: sl,en-US;q=0.7,en;q=0.3Accept-Encoding: gzip, deflate, brCookie: JSESSIONID=C01EF2741A88B0972EE1396A0BF53F33; _ga=GA1.2.1549015588.1508928512; __unam=4c2047a-15f5d927474-2100dacf-9; _gid=GA1.2.1624725319.1510145693; i18next=sl; _gat=1Connection: keep-aliveUpgrade-Insecure-Requests: 1

Rekono OIDC 26/34

OSI d.o.o.

Veljaven: različica 1.1

Če uporabnik nima veljavne Rekono seje, se bo moral avtenticirati na Rekono OpenIDConnect strežniku. Po uspešni avtentikaciji se uporabnik strinja da bo REST API aplikacija oziroma mobilna aplikacija imela dostop do njegovih izjav. Katere izjave potrebuje aplikacija se določi pri registraciji aplikacije. Ko uporabnik potrdi strinjanje bo Rekono OIDC strežnik vrnil odgovor v obliki URL 302 preusmeritve:

HTTP/1.1 302 FoundDate: Thu, 09 Nov 2017 12:47:53 GMTServer: Apache/2.4.6 (CentOS) OpenSSL/1.0.1e-fips mod_jk/1.2.40Cache-Control: no-cache, no-store, max-age=0, must-revalidatePragma: no-cacheExpires: 0Strict-Transport-Security: max-age=31536000 ; includeSubDomainsX-XSS-Protection: 1; mode=blockX-Frame-Options: DENYX-Content-Type-Options: nosniffLocation: com.google.codelabs.appauth:/oauth2callback2?code=FNXO3d6&state=2148198c7d866Content-Language: slContent-Length: 0Keep-Alive: timeout=5, max=100Connection: Keep-Alive

Mobilna aplikacija na mobilni napravi se aktivirac, ker ima registrirana “custom URI schemo” na katero se aktivira. Mobilna aplikacija bo prevzela redirect in poslala zahtevo za žetone na /token končno točko Rekono:

curl -X POST -u "c4460964-7d61-451c-8a12-ae486f5a036e:" -d "grant_type=authorization_code" -d "code=NXO3d6" -d "redirect_uri=com.google.codelabs.appauth:/oauth2callback2" https://idptst.rekono.si/openid-connect-server-webapp/token

Rekono strežnik vrne odgovor

HTTP/1.1 200 OKDate: Thu, 09 Nov 2017 13:00:22 GMTServer: Apache/2.4.6 (CentOS) OpenSSL/1.0.1e-fips mod_jk/1.2.40Access-Control-Allow-Origin: *Cache-Control: no-cache, no-store, max-age=0, must-revalidatePragma: no-cacheExpires: 0Strict-Transport-Security: max-age=31536000 ; includeSubDomainsX-XSS-Protection: 1; mode=blockX-Frame-Options: DENYX-Content-Type-Options: nosniffTransfer-Encoding: chunkedContent-Type: application/json;charset=UTF-8

{"access_token":"eyJraWQiOiJyc2ExIiwiYWxnIjoiUlMyNTYifQ.eyJzdWIiOiJtYXJrby5zbWlkQG9zaS5zaSIsImF6cCI6ImM0NDYwOTY0LTdkNjEtNDUxYy04YTEyLWFlNDg2ZjVhMDM2ZSIsImlzcyI6Imh0dHBzOlwvXC9pZHB0c3QucmVrb25vLnNpXC9vcGVuaWQtY29ubmVjdC1zZXJ2ZXItd2ViYXBwXC8iLCJleHAiOjE1MTAyMzYwMjIsImlhdCI6MTUxMDIzMjQyMiwianRpIjoiOTM3MmY4YWUtYTY5My00YTM2LTliYmItOGZlYThkN2IzNzU3In0.qiiY6Tjogx0V8JopL0rmIGEXf3UUlZV8r88HpAB3nKktqu5Uv6Im7VqwnTxrq_4sZYInnwIQavUky_0RgYvTmanuw9--tqWC_UKmIqqN8pEKBkdSKwY-ts1GVYUBbbUCJtpcIenFrb49KC3ZDWYqD04DSjCaRiGwtvIiUgJ5BuhnFbOLoutA0uYOmrjrA0HnRzk4INeUUdih8soDP4Ao8zsjDUMQ3KOncr7a7jbVMLQkICKbIVS9JMOhkqWLZWGNUtH6Fj-QsyNg-P1VseltP8RBt6KdDt-DN64PX86WwVZUdWdCpiRjHFLHzCHtVcFYp7o5INko-I513wP3y6L0yw","token_type":"Bearer","refresh_token":"eyJhbGciOiJub25lIn0.eyJqdGkiOiJjZDQ4YWMyOS00NTI4LTQ4MzgtOWE5Zi0zMTliYjhiMDg1YWIifQ.","expires_in":3599,"scope":"address phone openid offline_access profile http://idp.rekono.si/openid/taxnumber email","id_token":"eyJraWQiOiJyc2ExIiwiYWxnIjoiUlMyNTYifQ.eyJzdWIiOiIwMjY1MDA3MjI0IiwiYXVkIjoiYzQ0NjA5NjQtN2Q2MS00NTFjLThhMTItYWU0ODZmNWEwMzZlIiwia2lkIjoicnNhMSIsImlzcyI6Imh0dHBzOlwvXC9pZHB0c3QucmVrb25vLnNpXC9vcGVuaWQtY29ubmVjdC1zZXJ2ZXItd2ViYXBwXC8iLCJleHAiOjE1MTAyMzMwMjMsImlhdCI6MTUxMDIzMjQyMiwibm9uY2UiOiIyMDM4NWNmYWQ3Mzg0IiwianRpIjoiZmI4YTQ3OTMtOTAyZS00MzM2LTk0MWQtOTM0MTQwNTYyYmEyIn0.KpNH0y1UFPLX2H_7pmzopnvF9_ohiz-

Rekono OIDC 27/34

OSI d.o.o.

Veljaven: različica 1.1

EGSm7Veo_YyLSvXE3jrF49vQKpJX4sNzvTll7g9FFHx-EKAUv590YJt-dyOXLywFZQR95soefETmMeyy1Pw2tmFB7NV8UO2sbKDhAqsuqOW_0hb3JSKbqjmUlB-jx4A61yx26wj1ATwiTIIYi1cFBkynoPx9m7hAGJauv6pS7RBHrobh-8CO23uQ4vU2UJa6Zj_SJALnPhRB0w9cGhsN7PkYzLGamRvxJP3jfpCe0KqrI1kKBgcDs7na2CV0fQMs6ftNMwBSCRCC2DIVtmZOD_ZqaI_Quwd2mkhy9x1QD7eOCtEm4HUcjOg"}

Mobilna aplikacija je pridobila tri žetone: access_token: namenjen kot bearer token za REST API aplikacijo; refresh_token: namenjen mobilni aplikaciji za možnost obnavljanja

access_token žetona; id_token: id_token vsebuje Rekono OIDC sejo.

Mobilna aplikacija mora preveriti access_token in id_token.

2. Dostop mobilne aplikacije do podatkov uporabnikaMobilna aplikacija ima veljaven access_token in ga posreduje REST API aplikaciji

REST API aplikacija prejme access_token (npr. v Authorization Bearer polju HTTP zahteve).

REST API preveri veljavnost access_token-a. /introspect in preveri JWT podpis.

Iz /introspect pridobi mobilna aplikacija enoznačni podatek uporabnika (polje sub). Tapodatek je rekonoID, ki je povezan z zalednimi podatki uporabnika.

REST API aplikacija izvaja klice za poizvedbo za podatki uporabnika.

Mobilna aplikacija nima več veljavnega access_token žetonaMobilna aplikacija hrani access_token varovano v pomnilniku. Ko access_token poteče, ali ko uporabnik ponovno starta mobilno aplikacijo, mobilna aplikacija uporabirefresh_token.

S POST klicem /token in vsebino grant_type=refresh_token&refresh_token=vrednost_token-a mobilna aplikacija zahteva nove žetone.

Novi access_token, mobilna aplikacija preveri, opcijsko preveri podatke uporabnika prek id_token-a in novi access_token uporabi za klic REST_API aplikacije.

Odjava iz aplikacijeZa odjavo iz aplikacije, aplikacija ne izvede neposrednega brisanja sej. Enostavno aplikacija prekliče oba žetona (/revoke):

access_token refresh_token

Mobilna aplikacija pobriše refresh token iz varovanega skladišča.

Ko bo mobilna aplikacija želela podatke od REST API aplikacije, bo zahtevala nov access_token. Ker access_token-a nima, bo želela uporabiti refresh token. Ker tudi tega nima, sproži authorization_code delovni tok pridobivanja žetonov. V authorization_code foo-u pa bo Rekono strežnik zahteval ponovno avtentikacijo. Po končanem authorization_code delovnem toku, ima mobilna aplikacija nove žetone:

access_token, refresh_token id_token.

Rekono OIDC 28/34

OSI d.o.o.

Veljaven: različica 1.1

Ker se avtentikacija uporabnika izvede v “sistemskem” brskalniku, ni mogoče izničiti centralne seje. Ko ima aplikacija neveljavne žetone, oziroma nima žetonov, le te zavrže in zahteva nov authorization_code delovni tok. Mobilna aplikacija lahko vedno v začetni zahtevi posreduje parameter

prompt=login

ki bo povzročil, da bo strežnik od uporabnika zahteval prijavo, ne glede na veljavnost prejšnje seje.

Obstaja tudi možnost, da centralno sejo popolnoma minimziramo. Težava lahko nastane edino v primeru prve registracije, ko je zaključek uspešne registracije, hkrati omogoči tudi prijava v aplikacijo. V tem primeru bi kratka seja lahko povzročila težave zaključka registracije uporabniškega računa (zato priporočamo uporabo “prompt=login” parametra v tačetni zahtevi).

Rekono OIDC 29/34

OSI d.o.o.

Veljaven: različica 1.1

UPRAVLJANJE REKONO OPENID ODJEMALCEV

Uporabniški račun(i) končne strankeZa vnos nove aplikacije v centralni avtentikacijski sistem Rekono, mora imeti pogodbena stranka, registriran Rekono račun s katerim izvaja upravljanje svojih aplikacij. Za upravljanje mora stranka uporabiti Rekono račun, ki je vezan na podjetje:

ime računa vsebuje email naslov, ki ima internetno domeno v lasti podjetja;◦ priporočamo uporabo namenskega email naslova, npr.

[email protected].;◦ lahko pa se uporabljajo tudi obstoječi uporabniški računi, ki so vezani na

podjetje; nivo identitete tega računa mora biti vsaj 20, kar pomeni, da je stranka na ta

račun povezala digitalno potrdilo kvalifciranega izdajatelja, oziroma je zaupanja vreden Rekono račun;

Ob prijavi z Rekono računom, ki ima dodeljeno posebno vlogo (dogovor med stranko in podjetjem OSI d.o.o.) lahko stranka upravlja svoje aplikacije, ki so povezane z Rekono OIDC.

Če stranka ne želi sama upravljati aplikacij, lahko zahtevo za registracijo aplikacije posreduje Rekono skrbnikom na naslov [email protected].

Registracija novega odjemalcaPred registracijo aplikacije na oba načina, mora stranka pripraviti naslednje podatke:

ime aplikacije: pod katerim bo aplikacija poznana končnim uporabnikom; URI za preusmeritev: URI na katerega bo preusmerjen “User-Agent” končne

aplikacije, po uspešni avtentikaciji uporabnika. To je URL, kjer končna aplikacija sprejme avtorizacijsko kodo, ki jo nato zamenja za vstopni žeton (access_token). URI je za spletne aplikacije v obliki npr. https://ime_spletne_storitve/login_oidc, za mobilne aplikacije pa je v enoznačniobliki, ki jo ima registrirana aplikacija. Ko mobilna naprava prejme ta preusmeritveni URI samodejno starta oziroma odpre URI v mobilni aplikaciji. Najbolj običajna možnost enoznačnega URI-ja je okoli obrnjeno internetno domensko ime aplikacije npr. si.rekono.idp://auth ali npr. osi000001://auth. Omejitev pri Windoos universal aplikacijah je dolžina tega polja, ki lahko vsebuje le 39 znakov.

logotip aplikacije: url do logotipa, ki se prikaže uporabniku pri prikazu stranistrinjanja s posredovanjem osebnih podatkov;

URL pogojev storitve: url do pogojev uporabe aplikacije/storitve. Ti pogoji so vidni uporabniku pri strani za strinjanje z obdelavo podatkov in pri upravljanju odobrenih aplikacij;

URL politike upravljanja osebnih podatkov: URL do politike upravljanja osebnih podatkov;

Domača stran: URL do domače strani aplikacije; Stiki: seznam skrbnikov operacije v obliki enoznačne oznake uporabnika. Stik

uporabnika, ki izvaja registracijo je samodejno dodan. Podatki Software ID, Software Version in Software statement so

uporabni pri dinamični registracije odjemalca.

V nadaljevanju na zavihku “Dostop” vpišemo podatke: Scope: nabor atributov, ki jih bo IDP/AS strežnik ob strinjanju uporabnika

Rekono OIDC 30/34

OSI d.o.o.

Veljaven: različica 1.1

posredoval končni aplikaciji;◦ pri odobritvi atributa davčne številke (taxnumber) je potrebno dodati

obseg z vnosom vrednosti http://idp.rekono.si/openid/taxnumber v vrstico za dodajanje atributov, zaradi napake delovanja spletnega vmesnika.

Grant Types: predlagamo uporabo delokroga “Avtorizacijska koda” kot najbolj varnega in primernega tudi za mobilne aplikacije.

Response Types: Response Types določa vrste elementov, ki jih vrača AS strežnik. Trenutno še ni v uporabi, zato predlagamo izbiro “code token id_token”.

V zavihku Poverilnice določimo kako se odjemalec predstavi AS strežniku: prek Basic Authorization polja v glavi http zahteve z vpisanim imenom in

geslom, ki ga dobi odjemalec ob zaključku registracije; posredovanja avtentikacije odjemalca prek HTTP POST zahteve in

posredovanje podatkov◦ client_id in client_secret v parametrih POST zahteve

geslo odjemalca vsebovano v JWT (Json Web Token) zahtevi, ki je podpisana ssimetričnim ključem;

geslo odjemalca vsebovano v v JWT (Json Web Token) zahtevi, ki je podpisanaz asimetričnim zasebnik ključem podpisnika;◦ v obeh zadnjih primerih je potrebno določiti algoritem podpisa;◦ in vpisati URL do mesta na odjemalcu za zajem javnega ključa, ali pa ključ

vpisati neposredno v formo v JWKS obliki. brez gesla odjemalca: v tem primeru odjemalec nima gesla in se predstavi le s

svjim client_id-jem.

V zavihku Šifriranje se priporoča, da se pustijo privzete vrednosti, torej algoritmi določene na strani strežnika.

V zavihku Drugo pustimo privzete vrednosti.

V tem primeru se določene privzete vrednosti za veljavnost žetonov: access_token žeton ima veljavnost eno uro (3600 sekund); id_token ima veljavnost 10 minut (600 sekund); refresh_token ima neomejeno veljavnost;

Privzete vrednosti se lahko določijo na nove vrednosti s strani administratorja sistema, ki lahko za vsako vrsto žetona določi druge časovne omejitve.

Refresh_token se izda, le če ga ima odjemalec določenega v obsegu nabora atributovin če ga odjemalec zahteva. V tem primeru se pri zahtevi za access_token v odgovoru posreduje tudi refresh_token.

Rekono OIDC 31/34

OSI d.o.o.

Veljaven: različica 1.1

REFERENCE

OpenID connect 1.0http://openid.net/specs/openid-connect-core-1_0.html

OpenID connect PKCE dodatna zaščitahttp://openid.net/2015/05/26/enhancing-oauth-security-for-mobile-applications-oith-pkse/

https://tools.ietf.org/html/rfc7636

OpenID connect upravljanje sejehttp://openid.net/specs/openid-connect-session-1_0.html#RPLogout

OpenID varnost in nedosledna implementacijahttps://medium.com/@darutk/full-scratch-implementor-of-oauth-and-openid-connect-talks-about-fndings-55015f36d1c3

https://ooo.noosecure.com/blog/2016/11/04/oauth-2-0-mobile-app-security/

Refresh tokenhttps://auth0.com/learn/refresh-tokens/https://developer.apple.com/library/content/documentation/Security/Conceptual/keychainServConcepts/01introduction/introduction.html#//apple_ref/doc/uid/TP30000897-CH203-TP1https://medium.com/@ericfu/securely-storing-secrets-in-an-android-application-501f030ae5a3

Uporaba mobile client knjižnichttps://ooo.pingidentity.com/en/company/blog/2016/03/10/using_appauth_to_enable_your_apps_oith_mobile_sso.html

openid implementacija Android mobile API: https://openid.github.io/AppAuth-Android/openid implementacija IOS mobile API: https://openid.github.io/AppAuth-iOS/

Facebook varnostna priporočila za varno uporabo oauth2 in openidConnecthttps://developers.facebook.com/docs/facebook-login/security#checklisthttps://developers.facebook.com/docs/facebook-login/access-tokens/

Google priporočila varne avtentikacije z zalednim RS strežnikomhttps://developers.google.com/identity/sign-in/android/backend-auth

Rekono OIDC 32/34

OSI d.o.o.

Veljaven: različica 1.1

OWASP certificate pinninghttps://ooo.ooasp.org/index.php/Certifcate_and_Public_Key_Pinning

PUSH notificationshttps://stackoverfoo.com/questions/9156099/push-notifcation-facility-for-mobile-oeb-apphttps://pushpad.xyz/pricinghttps://frebase.google.com/https://developers.google.com/cloud-messaging/http://pushkin.io/ (opensource push notifcations)

id_token timeouthttps://stackoverfoo.com/questions/25686484/ohat-is-intent-of-id-token-expiry-time-in-openid-connect

Google OpenidConnect and OAUTH2https://developers.google.com/identity/protocols/OpenIDConnecthttps://developers.google.com/actions/identity/oauth2-code-foo

JWT, JWKhttps://jot.io/ https://github.com/jotk/jjothttps://mkjok.org/https://auth0.com/docs/jokshttps://npm.runkit.com/jok-to-pem

Rekono OIDC 33/34

OSI d.o.o.

Veljaven: različica 1.1

Rekono Authrization ConnectRequestParameters

public String CLIENT_ID = "client_id";

public String RESPONSE_TYPE = "response_type";

public String REDIRECT_URI = "redirect_uri";

public String STATE = "state";

public String DISPLAY = "display";

public String REQUEST = "request";

public String LOGIN_HINT = "login_hint";

public String MAX_AGE = "max_age";

public String CLAIMS = "claims";

public String SCOPE = "scope";

public String NONCE = "nonce";

public String PROMPT = "prompt";

// prompt values

public String PROMPT_LOGIN = "login";

public String PROMPT_NONE = "none";

public String PROMPT_CONSENT = "consent";

public String PROMPT_SEPARATOR = " ";

// extensions

public String APPROVED_SITE = "approved_site";

// responses

public String ERROR = "error";

public String LOGIN_REQUIRED = "login_required";

// audience

public String AUD = "aud";

// PKCE

public String CODE_CHALLENGE = "code_challenge";

public String CODE_CHALLENGE_METHOD = "code_challenge_method";

public String CODE_VERIFIER = "code_verifer";

Rekono OIDC 34/34