Chamamos de login-social a inclusão de um botão no aplicativo/site do parceiro para que seja delegada a autenticação para a Iônica.
Abaixo dois exemplos de como poderia ficar o botão de login-social da iônica no seu aplicativo/site. Neste link é possivel conferir as cores, tamanhanos e assests recomendados pelo nosso time de UX.
O botão de login-social deve apontar para o mesmo endereço que inicia o fluxo de SSO. Desta forma, quando o usuário clicar no botão de login-social, iniciará o fluxo de SSO, que irá redirecionar o usuário para a página de autenticação da Iônica (ADB2C). E após o usuário informar corretamente seu usuário e senha, retornará para o parceiro com as credencias (exatamente como no fluxo iniciado pelo menu-global). Abaixo um exemplo de URL para onde o botão de login-social deve apontar:
https://{urlparceiro-ambiente}/ionica/oauth2?iss=https://{apim-ambiente}&redirect_uri=https://{urlparceiro-ambiente}/ionica/homeOnde {urlparceiro-ambiente} corresponde a URL do parceiro para o ambiente a ser configurado e {apim-ambiente} deve ser substituído pela URL do ambiente FTD :
DEV - ftd-apim-dev.azure-api.net
HML - ftd-apim-hml.azure-api.net
PRD - ftd-apim-prd.azure-api.net
A escola que o professor deseja acessar é retornada no campo "selected_school" do id_token, permitindo ao Parceiro personalizar sua aplicação de acordo com a escola selecionada. No id_token, também retornamos a quantidade de escolas que o usuário possui no campo "qdt_schools". Caso o usuário possua mais de uma escola, o parceiro deverá exibir um botão para que o usuário troque de escola. Este botão tem implementação semelhante ao login-social, onde o usuário será enviado para o ADB2C da iônica para selecionar a escola, e retornará ao parceiro com um novo token, contendo a nova escola desejada. A implementação do botão de troca de escolas pode ser consultado nos "Projetos Modelos" abaixo.
Ao clicar no botão login-social da Iônica, o usuário é direcionado para tela de login da iônica, e após se autenticar com sucesso na iônica, ele é redirecionado de volta para o aplicativo do parceiro já autenticado.
O funcionamento técnico é exibido na imagem abaixo. Para facilitar a integração, desenvolvemos "projetos-modelos" implementando esse fluxo. Dessa forma, nossos parceiros podem seguir essas implementações de referencia e realizar a integração de forma rápida e segura, se preocupando apenas com a etapa 1 do digrama.
Abaixo os links dos projetos modelo, em cada projeto tem uma arquivo readme com maiores instruções.
Obs: Os projetos modelos estão configurados com credenciais de teste válidas para o ambiente de desenvolvimento da Iônica. Após o parceiro realizar a integração com sucesso utilizando essas credenciais, a FTD irá fornecer as credenciais definitivas do parceiro (para cada ambiente).
Antes era solicitado ao Parceiro implementar uma validação de licença, caso não encontrasse o usuário em seu banco de dados. Esta validação permitia descobrir se o usuário não havia sido integrado porque a sincronização não aconteceu, ou se o usuário não foi integrado porque não tinha licença.
Agora realizamos essa validação de licença na Iônica, portanto, caso o usuário inicie o login-social pelo site/app do Parceiro, e não possua licença para o mesmo, será exibida uma tela de erro na Iônica, e o usuário não será redirecionado de volta ao Parceiro.
Obs: Caso o Parceiro tenha implementado essa validação, ela poderá ser removida, pois só serão re-direcioandos para o Parceiro usuários com licença. Se o usuário não existir no banco de dados do Parceiro, significa que ocorreu uma falha na sincronização ou a mesma ainda não aconteceu.
Para que possamos identificar a origem dos acessos, é necessário que o Parceiro envie os dados abaixo como query string para nossa URL de autorização:
origin: enviar "MenuGlobal" ou "LoginSocial"
is_app: enviar "1", para os casos onde o login-social é realizado por meio de uma aplicativo, ou "0" caso contrário. Obs: Caso o acesso seja realizado pelo site utilizando um celular, o valor a ser enviado deve ser "0".
Para os aplicativos, é possivel consultar uma referencia de implementação no tópico "Projetos Modelos" acima.
Para WEB, consultar a página de referencia LTI / SSO.
Um exemplo de como esses parametros devem aparecer na URL de autorização:
https://ionicahml.b2clogin.com/ionicahml.onmicrosoft.com/oauth2/v2.0/authorize?p=B2C_1A_SignUpOrSignIn&client_id=ad91bedb-e5fb-40ea-9afa-bd4ae429dc65&redirect_uri=https%3A%2F%2Fhome.souionicahml.com%2F&scope=openid&response_type=id_token&prompt=login&email_hint=squad5.colecoes%40mailinator.com&origin=LoginSocial&is_app=0
É recomendado que seja feita a validação do token recebido após o login para garantir que ele foi devidamente assinado pela FTD. Abaixo as URLs onde podem ser encontradas as chaves para validação de acordo com o Issuer do token adquirido.
ADB2C
https://ionicadev.b2clogin.com/ionicadev.onmicrosoft.com/b2c_1a_signuporsignin/discovery/v2.0/keys
https://ionicahml.b2clogin.com/ionicahml.onmicrosoft.com/b2c_1a_signuporsignin/discovery/v2.0/keys
https://ionicaprd.b2clogin.com/ionicaprd.onmicrosoft.com/b2c_1a_signuporsignin/discovery/v2.0/keys
LTI-Launch GM
https://api-dev.grupomarista.org.br/public/ftd/lti-launch-api/v1/auth/jwks/{clientId}
https://api-uat.grupomarista.org.br/public/ftd/lti-launch-api/v1/auth/jwks/{clientId}
https://api.grupomarista.org.br/public/ftd/lti-launch-api/v1/auth/jwks/{clientId}
LTI-Launch FTD
https://ftd-apim-dev.azure-api.net/lti-api/v1/auth/jwks/{clientId}
https://ftd-apim-hml.azure-api.net/lti-api/v1/auth/jwks/{clientId}
https://ftd-apim-prd.azure-api.net/lti-api/v1/auth/jwks/{clientId}