Best posts made by mgetka

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.

I'm not really familiar with ASP, so your code and traces says little to me. But knowing a bit about OAuth2 and OIDC I would blame missing state parameter in your authorize URL. Many frameworks use it to perform kind of CSRF protection, to check whether the client returning from login page initiated the authorization flow in the specific application. So, classically, your authorization URL (the one pointing to /oauth2/authorize endpoint of the FA) should be generated somehow by you OIDC library. The library will take care, about all the parameters including the state parameter. If you wish to construct the URL on your own, you probably need to initialize internal state representation in you lib, and then somehow get the value and include it in the authorization url.

Refer to OAuth2 realted resources If you wish to get more information on the role of the state parameter. Personally, I've found OAuth 2.0 Simplified by Aaron Parecki very informative. The state parameter is mentioned in Authorization Code Grant chapter.

BTW, typically, the /oauth2/authorize page is not embedded in the iframe - the user is rather redirected to it. I don't know what is your particular use case, but i suppose that you may have difficulties stemming from the iframe approach once you resolve the current issue.

Yesterday you asked about email personalization in another topic and received a reply there. Email avatars are things specific to email client software - you need to search through yahoo mail related resources to get your answer. Be aware that other email clients, like gmail, have its own approach on avatars - they are not a subject to any standardization. Passwordless hosted page appearance can be modified by FreeMarker template - you can find all the necessary instructions in the docs.

The logout from other devices functionality is based on access and refresh tokens. To implement it, you should configure access tokens to be short lived, and restrict access in your services backend only to users that authorize themselves with a valid access token. Since the tokens are short lived, your applications will require refresh tokens to obtain new access tokens when the old ones expire.

With such preconditions fulfilled, the logout form other devices functionality is all about revoking the refresh tokens provided for other devices. The other devices will still be able to utilize the session, but no longer than access token validity period (that cannot be revoked). Once it expires, they will try to obtain new one using the refresh token but this request will be denied - at this point, the device can be considered logged out.

There is no way to redirect a user anywhere via webhook. Webhooks requests are made internally by the FA and only FA receives its response.

Use FreeMarker templates to tailor the default page shown by the FA on such event to your needs. If for some reason it is really necessary to redirect a user somewhere else you can edit the page to initiate the redirect via HTML meta tags or javascript.

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.

If you have mor than one tenant defined (as you have) then tenant selection dropdown appears in the application creation view. Create chosen application in the second tenant and discard it in the first one.

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.

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.

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.

Are you using custom pseudo-protocol scheme in the app redirect URL?