API based login flow

[bernljung]

This PR adds support for an API based login flow. This is needed for certain clients such as native iOS and Android apps, to avoid the extra step of opening a webview for Bankid login. It could also be useful for more advanced web apps that wants to be in full control of their UI elements.

The existing endpoints for start, collect, done and cancel are mirrored with API based equivialents that returns JSON instead of the HTML template.

Which flow to use is decided by the client application by using the querystring bankid_login_flow when calling the initial /auth endpoint. It defaults to the current flow (which I call webview) for full backwards compatibility.

Not 100% sure of the best way of how the choice of login flow is to be made, a few ideas I had:

1. Use a query string as implemented. I think this makes the most sense as it hands full freedom to the client developers.
2. Create an additional configuration setting where we could specify client ids that should default to api. (might be good as a comliment to 1)
3. Register two separate IdentityProviders in KC that the clients can choose by the kc_idp_hint querystring. Would require separate configurations which may be a good or bad thing as it gives some extra control but it adds some potential work.

Feedback appreciated! 🙂

resolves #43

[bernljung]

ping @ullgren

[ullgren]

@bernljung Thanks for the PR and the ping. Will have a look at it.

[harikant-lftt]

@bernljung

I have a question in this PR.
Basically I want to run First broker login flow with first two step enable

Lat say we have userid based Authentication along with Bankid, Now I want to Enable Profile verification flow and linking so that one user can login with Email and BankId both. How it will be possible.

CC @ullgren

[bernljung]

@harikant-lftt To allow login with either username/password or BankID you'd use a browser flow with a Username Password Form execution. If you have the Bankid Identity Provider enabled, the default form includes a button to login with BankID should the user want to use that flow instead. Is this what you had in mind?

Note that showing a form instead of using the Identity Provider Redirector execution won't work for the clients wanting to use the api based flow included in this PR, as it has to return JSON instead of HTML directly. Instead you might consider using separate browser flows depending on the client used. So that web based clients get the form while as native such as iOS and Android gets the api based BankID flow directly. (only Identity Provider Redirector)

And as for the Review Profile I don't think that is something you'd want to enable for a BankID login since it lets the user override the identification details received from BankID. What is it that you want to achieve?

[harikant-lftt]

There always possibility to enable profile review, let assume we want capture user email from KC, or may tomorrow we want to enable OTP feature or KC how we will able to do it.

This solution will only work when we are sure other than BANKID authentication we are not going to use any other KC IAM feature.

[bernljung]

@harikant-lftt I see your point with regards to compatibility. 👍

But at the same time, it would still work to use different auth flows based on the client used so you can get the behaviour you need for web based clients.

We could also tweak the /api/done endpoint to include extra data for the BrokeredIdentityContext, such as email, to store on the user in KC and allow a native implementation of the Profile Review after login is successful.

I also think that given how BankID is being used in a very large majority of applications, it is not an issue to NOT support adding things like OTP. It is simply not a use case when you have BankId, and proper documentation that covers what is and what isn't supported for the api flow should be sufficient in my opinion.

I have never seen BankId being used along side alternative IdP's. But IF that would be the case, we could also add a switch to be able to turn on/off the API flow from the IdP configuration so that it won't be triggered by mistake, though unlikely.

Maybe @ullgren has some input on this matter.

[bernljung]

Thoughts @harikant-lftt @ullgren ?

[petternordlanderhelo]

I have never seen BankId being used along side alternative IdP's. But IF that would be the case, we could also add a switch to be able to turn on/off the API flow from the IdP configuration so that it won't be triggered by mistake, though unlikely.

I don't really think this is valid. There seems to be a movement in society to roll out Freja eID+ (that has OIDC support) alongside BankID as an alternative. But I guess that can be worked around using multiple clients?