Paucis abhinc mensibus ante OpenID server ad effectum deducendi ut accessum pro centum applicationum internarum nostrarum administrarem. Ex nostris progressibus, minore modo opportuno, ad regulam receptam commoti sumus. Accessus per ministerium centrale significanter operationes fastidiosas simplificat, sumptus exsequendi licentias minuit, multa parata solutiones reperire sinit, nec cerebra tua excruciare cum novas evolvit. In hoc articulo ego de transitu et labefecit quod ferire potuimus.
Jamdiu... Ubi omnes coeperunt
Aliquot abhinc annis, cum applicationes internae nimis multi factae sunt ad operandum manuale, applicationem scripsimus ad accessum moderandum in societate. Simplex erat applicationis Rails quae datorum cum informationibus de operariis coniungitur, ubi accessus ad varias functiones configuratus est. Eodem tempore primum SSO immissa, quae verificatione innixa est a cliente et auctoritate servientis, signum in forma encrypted cum pluribus parametris transmissum est et in servo auctore comprobatum est. Optio haec non fuit aptissima, cum singulae applicatio interna ad logicam iacum describendam pertineat, et operariorum datorum possibilitatem prorsus congruere cum servo cessionis.
Post aliquod tempus placuit munus auctoritatis centralised simpliciorem reddere. SSO ad libratorem translatus. Ope OpenResty, exemplum Luae signa obpressa addita est, scivit quam applicationem petitum iri et inspicere posset num aditus ibi esset. Hic accessus valde facilior fuit munus moderandi accessum ad applicationes internas - non iam opus erat logicam additam describere in uniuscuiusque applicationis codice. Quam ob rem commercium exterius clausimus, sed applicatio ipsa de auctoritate nihil scivit.
Sed una quaestio dubitatur. Quid de applicationibus quae molestie informationem indigent? Licuit scribere API pro concessionis servitio, sed tunc debetis addere logicam additam pro unoquoque applicatione. Praeterea dependentiam ab applicationibus nostris auto-scriptis removere voluimus, quae adhuc in translatione in OpenSource, in auctoritate interna servitore nostro notavimus. Dicemus tibi alio tempore. Solutio utriusque quaestionis OAuth.
Ad signa receptus
OAuth clarum est, generaliter auctoritatis signum acceptum, sed quia sola eius officiatio non sufficit, OpenID Connect (OIDC) statim consideratur. OIDC ipsa tertia est exsecutio normae authenticationis apertae, quae evolvit in superset OAuth 2.0 protocollum (Protocol LICENTIA Open). Solutio haec problema solvit defectus notitiarum circa finem utentis, et etiam efficit ut provisor licentiae possit mutare.
Autem, provisor specificam non eligimus et integrationem cum OIDC addere decrevimus pro servo nostro existentium auctoritatis. Hoc consilium confirmabatur ex eo quod OIDC valde flexibile est secundum finem-usoris auctoritatis. Ita fieri potuit ut OIDC subsidium in tuo currenti rato servitore efficere posset.
Via nostra ad exsequendam servo nostro OIDC
I) notitia requiritur ad formam infer
Ad integrandum OIDC, necesse est ut usorem currentem in notitias formas per modum comprehensibiles perducas. In OIDC haec dicta dicta. Notae essentialiter sunt ultimae agri in database utentis (nomen, inscriptio, telephonum, etc.). Est et omne quod in hoc catalogo non ponitur consuetudo habetur. Primum igitur quod debes attendere ad eligendum si vis provisor existens OIDC est facultas convenienter consuetudini novae notae.
Circulus notarum coniungitur in hoc subset - Scope. In auctoritate, accessus postulatur non ad notas specificas, sed ad scopes, etiamsi notae aliquae ex scopo non requiruntur.
II) peracta necessaria concessionibus
Altera pars integrationis OIDC est selectio et exsecutio cessionis generum, quae vocatur grants. In ulteriore applicatione missionis commercii inter delectos et servo concessionis in concessione selecta pendebit. Schema approximatum ad ius concessionis eligendum in figura infra exhibetur.
Ad primam applicationem, in concessione communissima usi sumus - LICENTIA Codicis. Ab aliis differentia est quod est triplex gradus, i.e. additional probatio patitur. Primum, utens petit licentiam concessionis, Codicis signum LICENTIA accipit, deinde hoc signo, quasi tessera peregrinata, signum aditum postulat. Omnis principalis commercium huius concessionis missionis fundatur in redirectibus inter applicationem et potestatem servo. Plura de hac donatione legere potes .
OAuth conceptui inhaeret accessum percepisse signa post concessionem temporalem esse ac potius mutare in mediocris singulis 10 momentis. Codicis LICENTIA concessio est triplicem verificationem per redirectiones, ad talem gradum singulis 10 minutis, libere loquendo, munus non est iucundissimum. Ad hanc quaestionem solvendam alia est concessio - Thochen Refresh, quo etiam usi sumus. Omnia hic simpliciora sunt. In confirmatione ex alia concessione, praeter signum accessum principale, aliud editur - Renovare Thochen, quod semel tantum adhiberi potest et vita eius, ut regula, signanter longior est. Cum hoc Thochen Renovare, cum TTL (Tempus Vivendi) principalis accessus indicio finitur, petitio novi accessus tessera perveniet ad finem alterius concessionis. Usus Renovare Thochen statim ad nihilum reset. Haec perscriptio duplex gradus est et in curriculo perfici potest, ab usore ignoratur.
III) Configured user notitia output formats
Cum concessiones selectae perficiantur, opera auctoritas est, digna acceptione finis usoris notitiae. OIDC hoc punctum separatum habet, ubi usorem datam postulare potes indicium accessus currentis et si hodie est. Et si usoris notitia toties non mutat, sed necesse est ire pro currentibus multis temporibus, solutionem venire potes ut signa JWT. Haec signa etiam vexillum confirmant. Vestigium ipsum JWT tribus partibus constat: caput (informatio de signo), payload (quaelibet data necessaria) et subscriptio (subscriptio, tessera a servo signata et in posterum fontem subscriptionis eius reprimere potes).
In OIDC inserendum, signum JWT id_token appellatur. Peti potest una cum iusto signo accessus et omnia quae supersunt ut subscriptionem comprobaat. Ad hanc rem, servo auctore potestatem singularem terminum habet cum fasciculo clavium publicarum in forma . Et de hoc memorandum est, quod alius terminus est, qui sumitur secundum mensuram hodiernam figuram OIDC ministrantis reflectit. Omnes inscriptiones limitis continet (inclusa inscriptione anuli clavi publici signandi adhibita), notas et scopas suffultas, encryption algorithms adhibitas, concessiones fultae, etc.
Exempli gratia in Google:
{
"issuer": "https://accounts.google.com",
"authorization_endpoint": "https://accounts.google.com/o/oauth2/v2/auth",
"device_authorization_endpoint": "https://oauth2.googleapis.com/device/code",
"token_endpoint": "https://oauth2.googleapis.com/token",
"userinfo_endpoint": "https://openidconnect.googleapis.com/v1/userinfo",
"revocation_endpoint": "https://oauth2.googleapis.com/revoke",
"jwks_uri": "https://www.googleapis.com/oauth2/v3/certs",
"response_types_supported": [
"code",
"token",
"id_token",
"code token",
"code id_token",
"token id_token",
"code token id_token",
"none"
],
"subject_types_supported": [
"public"
],
"id_token_signing_alg_values_supported": [
"RS256"
],
"scopes_supported": [
"openid",
"email",
"profile"
],
"token_endpoint_auth_methods_supported": [
"client_secret_post",
"client_secret_basic"
],
"claims_supported": [
"aud",
"email",
"email_verified",
"exp",
"family_name",
"given_name",
"iat",
"iss",
"locale",
"name",
"picture",
"sub"
],
"code_challenge_methods_supported": [
"plain",
"S256"
],
"grant_types_supported": [
"authorization_code",
"refresh_token",
"urn:ietf:params:oauth:grant-type:device_code",
"urn:ietf:params:oauth:grant-type:jwt-bearer"
]
}Ita, hoc_ signo, omnes notas necessarias ad pignus payload transferre potes et non servo licentiae contactum omni tempore ad usorem data petendi. Incommodum accessionis est quod mutationes in usuario datae a servo non statim veniunt, sed cum novo accessu indicio sunt.
Effectus exsequendam
Itaque, OIDC servitore nostro exsequendo et nexus cum eo in parte applicationis constituentes, problema usoris informationis tradendae solvemus.
Cum OIDC vexillum apertum sit, nunc optionem habemus eligendi provisoris existentis vel exsecutionis servientis. Conati sumus Keycloak, id quod evasit facillime ad configurandum, constituendo ac mutato connexione figurarum in parte applicationis, ire paratam est. In parte applicationis, omne quod restat, est mutare nexum figurarum.
De solutionibus existentium
In nostra ordinatione, ut primus OIDC minister, exsequendum nostrum collegimus, quod necessario suppletum est. Post accuratam interrogationem aliarum solutionum paratarum, dicere possumus hoc punctum controversiae esse. Deliberatio de instrumento nostro ministro agebatur sollicitudinibus provisoribus circa indigentiam necessariae functionalitatis, necnon praesentia veteris systematis, quod varias consuetudines auctoritates pro aliquibus officiis continebat et iam satis multa notitias circa operarios conlocavit. . Tamen in exsecutionibus praeparatis, sunt commoditates integrationis. Exempli gratia, Keycloak suum usoris administratione systema habet et notitia directe in ea reposita est, et usores tuos movere difficile non erit. Ad hanc rem, Keycloak habet API qui te permittit ut omnes actiones translationis necessarias plene exsequaris.
Alterum exemplum certificati, interesting, ut opinor, exsecutio est Ory hydra. Est interesting, quia constat ex diversis componentibus. Ad integrandum, necesse est ut tuam administrationem usoris coniungas servitio suo cessionis servitii ac prout opus est expand.
Hydra Keycloak et Ory solutiones solae paratae non sunt. Optimum est eligere exsecutionem ab OpenID Foundation certificatam. Hae solutiones typice habent insigne Certification OpenID.
Etiam oblivisci de provisoribus solvendis si non vis servo tuo OIDC servare. Hodie multae optiones bonae sunt.
deinde quid
In proximo futuro, alio modo ad officia interna mercaturas claudere pergimus. Commigrare monetam nostram SSO de librario per OpenResty ad procuratorem in OAuth molimur. Multae quoque solutiones hic paratae sunt, exempli gratia:
materiae additional
- bene opera reprehendo JWT signa
- list of certified OIDC implementations
Source: www.habr.com