"Third-party cookie will be blocked"

OAuth is already using a token based authentication.

For websites it is still common to store the credentials in a session and have a session cookie. This will still be possible since in most cases it is not a 3rd party cookie and since it is an essential cookie consent is also not needed. The advantage of sessions is that you have the authentication available in each request and you can restrict pages on the server when authentication is missing.

With API request from the client you can add extra headers to add an authentication token, but with the normal browser request you can’t while the session cookie is always being send.

The problem is for mobile app development where the app is mostly not running on the server but on the device and the server is seen as a 3rd party provider. Most mobile apps work with token based authentication, this means you must first request a token (can be an api key, oauth token, json web token etc.) and use that token in every request you make to the server.

So for websites the current Security Provider works fine and it will keep working even when 3rd party cookies are blocked. We need a new solution for when the server is being used as an API by a mobile app or a 3rd party domain.

We haven’t planned anything yet, so suggestions are welcome.

Wenn using a token we need to store it somewhere and bind it to a user, this would probably be in the database where also the users are stored. Alternative we could have the encrypted user credentials on the client (this is how the remember me cookie works) and send this with each API request, it does then a login with this credentials on each request. We could also provide all the methods and let you the developer choose which method to use, we then just create extra actions for token generation and encrypted user credentials.

5 Likes