When you try to utilize social sign-on in your android application, the page is not loading forever, it is actually being blocked. Redirecting to mobile applications is actually quite tricky. It has been some time since I was working on that matter but I will try to provide with most important insights on the topic.

So mobile app can register pseudo protocol, and once mobile web browser reach url with such schema, the application will be launched. If you register com.company.app as a scheme for your app, and then type in mobile web browser com.company.app://whatever your app will be launched - this works both on iOS and Android. But if you try to assign such url as an OAuth2 redirect_uri it will work on iOS but not necessarily on Android.

The issue is related to chromium security policies on redirects, and since system browsers on android are based on chromium engine it affects web views and other web based modals.

If the user directly types the custom schema url in the browser it will be allowed since the request was directly initiated by the user. If the user logs in via login & password, a chain of events occur (POST request, 302 response ...) that results in a custom scheme redirect, and finally, the redirect will be allowed since direct user action was the initiator of the chain. In the case of social sign on, we could think that the chain leading to the redirect is also initiated by the user, but the magic standing behind the login widgets breaks the chain, and chromium thinks that the redirect was arbitrarily initiated by some scripts rather than the user, so it is being blocked. Here is a link to long living chromium issue if you wish to track how things evolved through the time.

Finally, chromium thinks custom schemas are evil and we need to live with that. But OAuth2 needs to work in todays web, so there is another way - deep linking. Long story short, an application can register some specific URL (with http/https schema) that will lead to opening of the application. Such redirects are not blocked, and indeed it is a recommended way to perform application redirects on android.

So to sum it up, on iOS use pseudo protocol, on android use deep linking with http/https schemas... Nooo, it still not that easy Deep linking is not supported by older android versions, and those older versions allows for pseudo protocol redirects. So if you want to support older android devices that don't receive software updates since some time, you need to use pseudo protocol for them.

So to sum it up (for real this time), on iOS and older androids use pseudo protocol, on recent androids use deep linking with http/https schemas.

In my application, to accommodate the possible combinations, I've chosen to redirect iOS users directly to pseudo protocol. And redirect all the android user to a custom interstitial site. The URL of the site is registered via deep linking, so newer androids will redirect to the app with no fuss. For the older devices, under the address there is a simple page trying to perform redirect to pseudo protocol via javascript. As a last resort, if the user stays on the page for some time (so the javascript redirect didn't succeed), a link like "go back to the app" appears that allows an user to directly initiate the redirect - and this will always works. Example of such an interstitial page can be found at
AppAuth-Demo.

Some additional insights on the matter can also be found in this issue in okta-sdk-appauth-android
repository.

Long story short, docker-compose is a tool that facilitates running services composed of multiple containers. Personally, I have mixed feelings about snap, and use it only for a limited number of desktop GUI based applications, so I cannot help you with permissions issues. it would be most straight forward just to install docker-compose using the docker provided guide.

I would probably manage subscriptions outside of the FusionAuth, but looking through FA entities, user actions seems pretty promising. There, among other things, you have an option to set action (subscription) type, creator and expiration time, etc. Actions can also be revoked, and theirs history can be accessed. Finally, user action fetch API allows to return only active actions.

Ok, I've created a feature request.

Maybe I'm not searching through the docs thoroughly enough, but the effect of the asymmetric signing key expiration is not clear to me. Will it be automatically re-generated based on original configuration or will it be just marked inapplicable for cryptographic operations? If the latter is correct, what will happen with configuration relying on such key - I am referring to tenant or application JWT keys settings?

Registrations are different things than users - they associate users and applications. You can find more info on that in the documentation. deleteUser method should be used to delete a user.

lately, I've created a feature request on the suspicious login attempt detection capabilities. If I've been to creates such service my starting point would be client IP (for geolocalization) and user-agent string (maybe all headers) for browser fingerprinting of sorts. Still, login success/failure events summary contained in webhook call contains no useful information for such scenario

You can implement any password hashing scheme as a plugin and load it into FusionAuth. Then you simply migrate the user using new scheme. There is a tutorial on that matter in the docs.

I want to provide an user with a different password change/set form, depending on whether the user has the password or not. Users without a password are those who have so far authenticated only via external IDPs. I cannot find any API that provides such information. I thought that maybe, since the user has no password, the user.passwordLastUpdateInstant attribute will be empty, but it has the same value as user.insert

You need to create FreeMarker email template. Be aware that due to limitations of various email clients, designing of HTML email template is actually as frustrating as web development in the era of Internet Explorer 8. responsive-html-email-template stands as a pretty good starting point for such task. The repository readme file tells you what to consider when creating such a template.

Hi FusionAuth community!

I'm preparing an upgrade of a FusionAuth instance embedded in my system. The update is quite a big leap - from 1.33.0 to the latest 1.43.1 version. Across those versions lots of changes appeared, so some tweaks in the runtime environment and supporting services were inevitable, but eventually all is working as expected. With one exception - SSO flow with MFA enabled.

In my system I have a set of independent services that are registered in FA as independent applications. Up until now, our users entered the system by accessing one of those services - the service then redirected the user to complete OAuth2 flow via hosted login pages. If the user decided to navigate to other service, then, the authentication (in the scope of the other service) would be performed without user interaction - since he have an active FusionAuth SSO session the whole authentication drills down to just a bunch of 302 redirects. in 1.33.0, the whole process looked the same with or without MFA enabled, with the exception, that the user was asked for the second factor during the initial sign on (when accessing the first service).

After upgrading the process looks different. The first authentication looks the same, but when the user switches between the services, he is being asked for the second factor - he doesn't need to provide username and password (this is what SSO is all about, yes?) but is being asked to provide second factor on each new service accessed.

The new behavior significantly breaks the UX of my system, and I'm looking for an option that allows to tune FA policies to behave like in 1.33.0. Is this behavior anyhow configurable?

As an additional context I have Multi-Factor policies set to Enabled on the tenant level. The setting is not overridden in any of the FA applications. The whole described journey of a user across all the services happens in the scope of a single web browser session, and without the use of the trust this computer for 30 days option.

When you try to utilize social sign-on in your android application, the page is not loading forever, it is actually being blocked. Redirecting to mobile applications is actually quite tricky. It has been some time since I was working on that matter but I will try to provide with most important insights on the topic.

So mobile app can register pseudo protocol, and once mobile web browser reach url with such schema, the application will be launched. If you register com.company.app as a scheme for your app, and then type in mobile web browser com.company.app://whatever your app will be launched - this works both on iOS and Android. But if you try to assign such url as an OAuth2 redirect_uri it will work on iOS but not necessarily on Android.

The issue is related to chromium security policies on redirects, and since system browsers on android are based on chromium engine it affects web views and other web based modals.

If the user directly types the custom schema url in the browser it will be allowed since the request was directly initiated by the user. If the user logs in via login & password, a chain of events occur (POST request, 302 response ...) that results in a custom scheme redirect, and finally, the redirect will be allowed since direct user action was the initiator of the chain. In the case of social sign on, we could think that the chain leading to the redirect is also initiated by the user, but the magic standing behind the login widgets breaks the chain, and chromium thinks that the redirect was arbitrarily initiated by some scripts rather than the user, so it is being blocked. Here is a link to long living chromium issue if you wish to track how things evolved through the time.

Finally, chromium thinks custom schemas are evil and we need to live with that. But OAuth2 needs to work in todays web, so there is another way - deep linking. Long story short, an application can register some specific URL (with http/https schema) that will lead to opening of the application. Such redirects are not blocked, and indeed it is a recommended way to perform application redirects on android.

So to sum it up, on iOS use pseudo protocol, on android use deep linking with http/https schemas... Nooo, it still not that easy Deep linking is not supported by older android versions, and those older versions allows for pseudo protocol redirects. So if you want to support older android devices that don't receive software updates since some time, you need to use pseudo protocol for them.

So to sum it up (for real this time), on iOS and older androids use pseudo protocol, on recent androids use deep linking with http/https schemas.

In my application, to accommodate the possible combinations, I've chosen to redirect iOS users directly to pseudo protocol. And redirect all the android user to a custom interstitial site. The URL of the site is registered via deep linking, so newer androids will redirect to the app with no fuss. For the older devices, under the address there is a simple page trying to perform redirect to pseudo protocol via javascript. As a last resort, if the user stays on the page for some time (so the javascript redirect didn't succeed), a link like "go back to the app" appears that allows an user to directly initiate the redirect - and this will always works. Example of such an interstitial page can be found at
AppAuth-Demo.

Some additional insights on the matter can also be found in this issue in okta-sdk-appauth-android
repository.

Another aspect in favor of the approach involving API keys is the fact that your application can control the process of data entities modification. To be more precise, your application may implement additional authorization and data sanitization checks. You may prevent a user form changing his user name each day or restrict phone numbers to some country. Notably, many of the FA entities features data attribute that can hold any information. FA has no knowledge of what is the purpose or type of those data, so it has no means of deciding whether to allow an user to change its content or not.

So summing it up - yes, it's up to you to authenticate an user (via JWT validation) and authorize the request, and if everything is ok, to perform the specific API operations with omnipotent API key. It is so, since what does authorize the request mean may be different for each application.

Anything special appears in the logs on startup?

long-string-here is a placeholder for the purpose of the forum post, or is it actually the key you're trying to create? If it is the latter, then it will cause conflict - keys values needs to be unique. If the masterKey variable is also set to long-string-here, then you will end up with only one key created and errors in the logs.

At this point, you may also consider creating a KickStart script that loads the basic configuration with mentioned API keys, groups etc. into a fresh FA installation. You've mentioned that you are working on a test installation, so during the further tests you will probably fill it again with new test data entities. If so, it will most likely be easier to recreate the FA with basic configuration via KickStart, rather than to pick unnecessary entities and delete them one by one. Such script also stands as a good documentation on what configurations has been made to meet your environment requirements.

This post may be a bit off the topic, but from my experience such approach quickly pays off, so you can at once solve your issue and boost up your testing environment ergonomics.

I would consider defining both positions and teams as groups. With such approach one user could have multiple positions - if it is an issue, you would need implement such restriction in your application.

Later on, you define set of granular permissions as roles. The user can obtain a permission (role) in two ways:

• explicitly - the user has specific role set,
• implicitly - the user is in a group (position/team) associated with the role.

$request["user"]["type"] = "admin";

The user entity has not type member. To make such a distinction you can use groups.

You can set registration verification template either via GUI ora API - it doesn't make a difference. Since registrations are application specific, you firstly need to enable application's registrations verification and then you can select the template. Via GUI it can be done in Edit Application > Registration.

But still, at the moment I'm rather confused, and don't really know what are you actually trying to achieve. I suppose that email verification is the only verification that you need, but that is just my guesing.

In the previos post you mentioned 530 error, now it is 503. Also, you haven't provided full trace, so my response was based on some guessing, and the fact that 530 is actually defined in SMTP. On the other hand 503 HTTP code may be returned by the FA on an event of elastic search issues.

503
The search index is not available or encountered an exception so the request cannot be completed. The response will contain a JSON body.

See Complete a Passwordless Login.

Passwordless template is used for passwordless email, so as you are using passwordless login flow, you need this template. This topic, started with the question about email verification, so I suppose you use this feature, and email verification template will be useful as well. As for the registration verification template, as I have recently written:

To sum it up, user entity, created on an user creation event represents an user. This entity contains the user email and its verification status. The user email verification email may be sent only on user creation.
The registration, is an entity that associates already existing user to a specific application. The registration is not related to user email nor its verification status. However, it can contain alternative username to be used by the user in this application only. On an event of registration creation, FA can send confirmation email, but it doesn't confirm user email, it only confirms whether the registration of an user in the application should persist.

So if you want users to confirm registrations in certain applications (in addition to verifying email addresses, which can be understood as account creation verification), configure the functionality, and prepare registration verification template.

530 Authentication required SMTP error means that your tenant SMTP configuration is invalid.

This is a valid result with clear cause described in the docs.

404
The user was not found. The response will be empty.

You need to understand that each tenant has its own, separate user base. So, if the user exists in one tenant, he doesn't necessarily exists in another. Anticipating your question, you cannot have a common user base for multiple tenants - If you want to have single user base, then work on a single tenant.

The code snippet I put in the post where I first mention the withTenantId method is actually such an example. When I recommended referencing the source code, I meant the code itself, not the docstrings - the logic behind the withTenantId method is quite simple, and the code describes mentioned effects (alteration of internal client state) in the most unambigious way.

If you need more verbose examples see the code below

<?php

require __DIR__ . '/vendor/autoload.php';

$apiKey = "5a826da2-1e3a-49df-85ba-cd88575e4e9d";
$client = new FusionAuth\FusionAuthClient($apiKey, "http://localhost:9011");

$request = array(
	"applicationId" => "c9a6f176-93df-4eaa-b67c-b651d18df60c",
	"loginId" => "user"
);
$result = $client->withTenantId("adca656e-4895-4a9e-ac2e-8b9ebebb5149")->startPasswordlesslogin($request);

var_dump($result);

?>

For such a call, the client invokes following HTTP API request

POST /api/passwordless/start HTTP/1.1
Host: [...]:9011
Accept: */*
X-FusionAuth-TenantId: adca656e-4895-4a9e-ac2e-8b9ebebb5149
Authorization: 5a826da2-1e3a-49df-85ba-cd88575e4e9d
Content-Length: 73
Content-Type: application/json

{"applicationId":"c9a6f176-93df-4eaa-b67c-b651d18df60c","loginId":"user"}