Hai uns meses, estaba a implementar un servidor OpenID Connect para xestionar o acceso a centos das nosas aplicacións internas. A partir dos nosos propios desenvolvementos, convenientes a menor escala, pasamos a un estándar xeralmente aceptado. O acceso a través do servizo central simplifica enormemente as operacións monótonas, reduce o custo de implementación de autorizacións, permítelle atopar moitas solucións xa preparadas e non apurar os cerebros á hora de desenvolver outras novas. Neste artigo, falarei desta transición e dos desniveles que conseguimos encher.
Hai moito tempo... Como comezou todo
Hai uns anos, cando había demasiadas aplicacións internas para o control manual, escribimos unha aplicación para controlar o acceso dentro da empresa. Era unha sinxela aplicación Rails que se conectaba a unha base de datos con información sobre os empregados, onde se configuraba o acceso a varias funcionalidades. Ao mesmo tempo, suscitamos o primeiro SSO, que se baseou na verificación de tokens do lado do cliente e do servidor de autorización, o token transmitiuse en forma cifrada con varios parámetros e verificouse no servidor de autorización. Esta non era a opción máis conveniente, xa que cada aplicación interna tiña que describir unha considerable capa de lóxica e as bases de datos dos empregados estaban completamente sincronizadas co servidor de autorización.
Despois dun tempo, decidimos simplificar a tarefa de autorización centralizada. SSO transferiuse ao equilibrador. Coa axuda de OpenResty, engadiuse a Lua un modelo que verificaba os tokens, sabía a que aplicación ía a solicitude e podía comprobar se había acceso alí. Este enfoque simplificou moito a tarefa de controlar o acceso ás aplicacións internas: no código de cada aplicación xa non era necesario describir a lóxica adicional. Como resultado, pechamos o tráfico externamente e a propia aplicación non sabía nada de autorización.
Non obstante, un problema quedou sen resolver. Que pasa coas aplicacións que precisan información sobre os empregados? Era posible escribir unha API para o servizo de autorización, pero entón terías que engadir lóxica adicional para cada aplicación deste tipo. Ademais, queriamos desfacernos da dependencia dunha das nosas aplicacións autoescritas, orientada no futuro á tradución a OpenSource, no noso servidor de autorizacións interno. Xa falaremos noutro momento. A solución a ambos os problemas foi OAuth.
a estándares comúns
OAuth é un estándar de autorización comprensible e xeralmente aceptado, pero como só a súa funcionalidade non é suficiente, inmediatamente comezaron a considerar OpenID Connect (OIDC). O propio OIDC é a terceira implementación do estándar de autenticación aberta, que se converteu nun complemento sobre o protocolo OAuth 2.0 (un protocolo de autorización aberta). Esta solución pecha o problema da falta de datos sobre o usuario final, e tamén permite cambiar o provedor de autorización.
Non obstante, non eliximos un provedor específico e decidimos engadir a integración con OIDC para o noso servidor de autorización existente. A favor desta decisión estivo o feito de que OIDC é moi flexible en canto á autorización do usuario final. Así, foi posible implementar o soporte OIDC no seu servidor de autorización actual.
A nosa forma de implementar o noso propio servidor OIDC
1) Achegou os datos ao formulario desexado
Para integrar OIDC, é necesario levar os datos actuais do usuario nunha forma comprensible polo estándar. En OIDC isto chámase Reclamacións. As reclamacións son esencialmente campos finais da base de datos de usuarios (nome, correo electrónico, teléfono, etc.). Existe , e todo o que non estea incluído nesta lista considérase personalizado. Polo tanto, o primeiro punto ao que cómpre prestar atención se quere escoller un provedor de OIDC existente é a posibilidade de personalización conveniente de novas marcas.
O grupo de distintivos combínase no seguinte subconxunto: Ámbito. Durante a autorización, pídese acceso non a marcas específicas, senón a ámbitos, aínda que non sexan necesarias algunhas das marcas do ámbito.
2) Implementou as subvencións necesarias
A seguinte parte da integración do OIDC é a selección e implantación de tipos de autorización, as chamadas subvencións. O escenario adicional de interacción entre a aplicación seleccionada e o servidor de autorización dependerá da subvención seleccionada. Na seguinte figura móstrase un esquema exemplar para escoller a subvención correcta.
Para a nosa primeira solicitude, utilizamos a subvención máis común, o Código de autorización. A súa diferenza con respecto a outros é que se trata dun tres pasos, é dicir. está a realizar probas adicionais. En primeiro lugar, o usuario fai unha solicitude de permiso de autorización, recibe un token - Código de autorización, despois con este token, coma se cun billete para viaxar, solicita un token de acceso. Toda a interacción principal deste script de autorización baséase en redireccións entre a aplicación e o servidor de autorización. Podes ler máis sobre esta subvención .
OAuth adhírese ao concepto de que os tokens de acceso obtidos despois da autorización deben ser temporais e cambiar preferentemente cada 10 minutos de media. A concesión do Código de Autorización é unha verificación en tres pasos mediante redireccións, cada 10 minutos para dar un paso deste tipo, francamente, non é a tarefa máis agradable para os ollos. Para solucionar este problema, hai outra subvención - Refresh Token, que tamén usamos no noso país. Aquí todo é máis doado. Durante a verificación doutra subvención, ademais do token de acceso principal, emítese outro: Refresh Token, que só se pode usar unha vez e a súa vida útil adoita ser moito máis longa. Con este token de actualización, cando remate o TTL (Time to Live) do token de acceso principal, a solicitude dun novo token de acceso chegará ao punto final doutra subvención. O token de actualización usado restablece inmediatamente a cero. Esta comprobación é de dous pasos e pódese realizar en segundo plano, imperceptiblemente para o usuario.
3) Configure formatos de saída de datos personalizados
Unha vez implementadas as subvencións seleccionadas, a autorización funciona, cabe mencionar a obtención de datos sobre o usuario final. OIDC ten un punto final separado para iso, onde pode solicitar datos de usuario co seu token de acceso actual e se está actualizado. E se os datos do usuario non cambian tantas veces e necesitas seguir os actuais moitas veces, podes chegar a unha solución como as fichas JWT. Estes tokens tamén son compatibles co estándar. O propio token JWT consta de tres partes: cabeceira (información sobre o token), carga útil (calquera dato necesario) e sinatura (sinatura, o token está asinado polo servidor e posteriormente podes comprobar a orixe da súa sinatura).
Na implementación de OIDC, o token JWT chámase id_token. Pódese solicitar xunto cun token de acceso normal e só queda verificar a sinatura. O servidor de autorización ten un punto final separado para iso cun grupo de chaves públicas no formato . E falando disto, cabe mencionar que hai outro punto final, que, baseado no estándar reflicte a configuración actual do servidor OIDC. Contén todos os enderezos de puntos finais (incluído o enderezo do anel de chaves público utilizado para a sinatura), marcas e ámbitos compatibles, algoritmos de cifrado utilizados, subvencións admitidas, etc.
Por exemplo en 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"
]
}Así, usando id_token, pode transferir todos os distintivos necesarios á carga útil do token e non contactar co servidor de autorización cada vez para solicitar os datos do usuario. A desvantaxe deste enfoque é que o cambio nos datos do usuario do servidor non chega inmediatamente, senón xunto cun novo token de acceso.
Resultados de implantación
Así, despois de implementar o noso propio servidor OIDC e de configurar as conexións con el no lado da aplicación, resolvemos o problema de transferir información sobre os usuarios.
Dado que OIDC é un estándar aberto, temos a opción de escoller un provedor ou implementación de servidor existente. Probamos Keycloak, que resultou moi cómodo de configurar, despois de configurar e cambiar as configuracións de conexión no lado da aplicación, xa está listo para funcionar. No lado da aplicación, só queda cambiar as configuracións de conexión.
Falar das solucións existentes
Dentro da nosa organización, como primeiro servidor OIDC, montamos a nosa propia implementación, que foi complementada segundo fose necesario. Despois dunha revisión detallada doutras solucións preparadas, podemos dicir que este é un punto discutible. A favor da decisión de implantar o seu propio servidor, houbo preocupacións por parte dos provedores pola ausencia da funcionalidade necesaria, así como a presenza dun sistema antigo no que existían diferentes autorizacións personalizadas para algúns servizos e bastantes. de datos sobre empregados xa estaban almacenados. Non obstante, en implementacións preparadas, hai comodidades para a integración. Por exemplo, Keycloak ten o seu propio sistema de xestión de usuarios e os datos almacénanse directamente nel, e non será difícil superar os seus usuarios alí. Para iso, Keycloak dispón dunha API que che permitirá realizar plenamente todas as accións de transferencia necesarias.
Outro exemplo de implementación certificada e interesante, na miña opinión, é Ory Hydra. É interesante porque consta de diferentes compoñentes. Para integrarse, terás que vincular o teu servizo de xestión de usuarios ao seu servizo de autorización e ampliar segundo sexa necesario.
Keycloak e Ory Hydra non son as únicas solucións dispoñibles. O mellor é escoller unha implementación certificada pola OpenID Foundation. Estas solucións adoitan ter un distintivo de certificación OpenID.
Ademais, non te esquezas dos provedores de pago existentes se non queres manter o teu servidor OIDC. Hoxe hai moitas boas opcións.
Que hai a continuación
Nun futuro próximo, imos pechar o tráfico aos servizos internos dun xeito diferente. Planeamos transferir o noso SSO actual no equilibrador usando OpenResty a un proxy baseado en OAuth. Xa hai moitas solucións preparadas aquí, por exemplo:
Materiais adicionais
- bo servizo para validar fichas JWT
- Lista de implementacións certificadas de OIDC
Fonte: www.habr.com