Login Social
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.
Integração WEB
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.com.br/ionica/oauth2?iss=https://ftd-apim-prd.azure-api.net&redirect_uri=https://urlparceiro.com.br/ionica/home
Integração Mobile
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.
Projetos Modelos
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).
Verificação de Licença
Caso o usuário não seja encontrado no banco de dados do parceiro, podemos ter dois cenários:
A - O usuário ainda não foi sincronizado via oneroster (seja por que a job ainda não rodou, ou por motivo de falha da integração)
B - O usuário pode não possuir a licença para acesso ao Parceiro
Neste caso, para confirmação, recomendamos que seja chamado o respectivo endpoint (dev/hml/prd), passando o crmId do usuário (este pode ser obtido através do token do usuário - via SSO ou pelo login-social), juntamente com o header Authorization com o mesmo token que é utilizado para as chamadas do oneroster.
DEV - https://ftd-apim-dev.azure-api.net/license-api/v1/check-license/{crmId}
HML - https://ftd-apim-hml.azure-api.net/license-api/v1/check-license/{crmId}
PRD - https://ftd-apim-prd.azure-api.net/license-api/v1/check-license/{crmId}
Caso a chamada deste endpoint retorne 200, quer dizer que o usuário tem licença e estamos no cenário A. Neste momento, o parceiro pode tentar realizar uma sincronização com o oneroster ou exibir uma mensagem solicitando que o usuário tente novamente mais tarde.
Se o retorno for 404, então o usuário realmente não possui a licença para visualizar os serviços do Parceiro, com isso, deve-se exibir uma mensagem informativa, indicando que deve procurar a administração da escola para ativação do mesmo.