Sorry for the ambiguous question and suuuuper late reply, I was help hostage by another project. 
..and thanks for the info, that helps me understand its intent.
What I was speaking about is seeing some of the metadata (device name, type) in the "Manage User" -> "Recent Logins" list to differentiate the logins. After some more exploring it does look like it shows up in "Manage User" -> "Session" instead though.
Thanks!
When using the login api you can supply a metaData object with info like name, type, description. It says:
This meta data is used to describe the refresh token that may be generated for this login request.
Assuming refresh tokens are enabled for the app how is this information involved? Originally I assumed this data would be provided (and displayed) with the login records, but apparently it has a different use.
Thanks!
Yea, that flexibility would be ideal IMO, although the registeredLogoutURLs should be workable for us at this point. FWIW that is actually the behavior I assumed before digging into the docs. I'll definitely add the issue to GitHub, as I think it's probably part of the path to getting OIDC Certification which appears to already have an issue.
Thanks!
LOL.. well.. minutes after posting this I decided to check out customizing the logout theme template and saw:
[#-- use allLogoutURLs to call the logout URL of all applications in the tenant, or use registeredLogoutURLs to log out of just the applications the user is registered for --]
[#list allLogoutURLs![] as logoutURL]
<iframe src="${logoutURL}" style="width:0; height:0; border:0; border:none;"></iframe>
[/#list]
So it does appear we can limit things just to those registered, which we'll definitely try. But would still be curious if the OpenID Connect Front-Channel Logout spec is to be expected or an option in some way.
Thanks! (again)
We have a head scratcher here that we'd love some clarification on regarding the OAuth/OIDC logout endpoint (/oauth2/logout).
In the docs for the endpoint it says:
Since 1.10.0 The logout behavior follows that of the OpenID Connect Front-Channel Logout specification. Additionally, the logoutUrl used for each application is determined as follows: The logoutUrl of the Application is used, if that isn’t set then the logoutUrl of the Tenant is used.
Looking at that spec it says:
OPs supporting HTTP-based logout need to keep track of the set of logged-in RPs so that they know what RPs to contact at their logout URIs to cause them to log out. Some OPs track this state using a "visited sites" cookie. OPs contact them in parallel using a dynamically constructed page with HTML <iframe src="frontchannel_logout_uri"> tags rendering each logged-in RP's logout URI.
Which seems ideal for our configuration, if I'm understanding correctly. Basically it keeps track of which applications the user logged into (potentially via cookie) and hits their logout URIs on logout.
However, the docs for the Logout behavior setting when creating an application says:
All applications - This is the default behavior. Logout out of the FusionAuth SSO, call each registered Logout URLs for the entire tenant and then redirect to the Logout URL registered for this application.
Which is different, and seems to be(?) the behavior we are seeing. Basically every application defined in the tenant is looped and their logout endpoint is hit, regardless if the user is even registered for the application -- which definitely isn't ideal for our situation: single tenant with many, many applications and a given user only has registered access to a few.
We've been doing a bunch of dev against FA lately, so we cleared all cookies, etc thinking we may have built things up to a crazy state, but the results didn't change. Not sure if there is anything further to look at, but even knowing which behavior is expected would help a lot.
Thanks!
-James
Thanks for all the info...
The multiple application route does sound doable with some FA API work (which we'll have anyway) and backend API work on our end. We are looking at an application per customer already, which this would then multiply by the number of 3rd party services we take on, but that's probably not an issue (at this point at least).
We're a pretty small team (4 developers) that's vastly outnumbered by salespeople. 
We'll definitely keep the pro services in mind, but I think there is enough for us to get started with. I have a feeling we'll be moving to the Developer service pretty quickly after launch though. As the LDAP integration and Reactor service is very appealing.
Honestly, thanks for your thoughts and time on this.. 
-James
Seems I may have found part of the answer on this GitHub issue.
Looks like the issue went from Backlog, to Designing, back to Designing last month. 
Hopefully that's a sign there is hope.
Thanks for the replies!
I guess the main thing I'm still struggling with is the use of OAuth "scopes" with FusionAuth. While our primary use for FA would definitely be authenticating our own applications using roles+groups for authorization (and where access to full user and registration info is "ok"), we would also need to use FA to delegate limited application access and user info to 3rd party applications.
For these 3rd party systems I was thinking the best route would be via OAuth2/OIDC, returning an access token limited to some scopes the remote application has access to, and an id token with limited OIDC user info claims. From my (admittedly limited) use of OAuth2 services implemented by others (GitHub, Auth0, etc) this is controlled by the scopes supplied (and agreed to) during the authorization request.
For example, OIDC has several scopes defined for requesting user info claims (profile, email, address, phone) during authorization. GitHub has many scopes defined for specific API acccess, like "repo:status" to allow API access to commit status messages.
But from what I can tell, scopes aren't really used by FA outside of:
The JWT lambdas definitely seemed promising, and I'm actually using them to extend the access token with some information, but AFAIKT they do not have any information about the scope(s) authorized to work with.
So at some level I still feel like I'm either overlooking something key, or perhaps our use case is just a little outside FA's focus. At this point we're still just kicking the tires, but I'd love to figure out a solution, as FA feels more comfortable and organized than alternatives in literally every other way -- which means a lot.
Kicking the tires w/ FusionAuth and really love things so far. Very well done 
There's just one thing I haven't been able to figure out:
Is there any way that user information (phone number, email, potentially custom data, etc) can be selectively filtered/limited so that an application doesn't have access to "everything" about the user ?
I realize that's a rather broad question, and may take some followup, but I'll give a couple examples:
/api/user and get (as far as I can see) very complete user data (including any custom user data, all registration data, custom registration data for other registrations, etc) regardless of whether they are even technically registered to the application they just authenticated with./oauth2/userinfo endpoint returns all claims about the user that would fall under the OIDC scopes of email, address, profile, phone, and openid, as the only scope options in FustionAuth seem to be offline_access and openid?Anyway, I'm definitely not an auth expert, and would gladly take a scolding and RTFM if I'm overlooking something or misunderstanding some concept. Really just looking for any insight.
Thanks!
-James