I am working on a Blazor web application with ASP.NET Identity added to it.
The account register/login functionality has all been added as MVC out of the box.
After the user has logged in, they interact with the Blazor app.
After they have logged in, they can perform an action which adds a Claim to their user. The Claim is added and I can see it in the ASPNetUserClaims table.
The next time the user logs in, the Claim is available in the Blazor code and the server side code.
However, immediately after adding the Claim (before their next login and for the rest of their session) the Claim is not available by default, e.g. using authState.User.Claims in Blazor, or User.Claims in an ApiController.
I believe this is because the claims are written into the user's JWT token when they login, and saved in their browser.
Is there a way to update the JWT token in the user's browser if they make a request that changes their Claims? Ideally using ASP.NET Identity?
Related
I have a Blazor WebAssembly app the uses Azure ADB2C for authentication via MSAL. Staring form the default project template most things work as expected (login, logout).
Single Sign On (SSO) kinda works. If I am already logged in with Azure and I go to a page that requires authentication the app will authenticate the user and correctly identify that the user is already logged in and show the page and the user will show as being logged in.
However, if the user start off on the app landing/home page which does not require authentication, no authentication is attempted and therefore the user does not get logged in.
We have an companion Xamarin app the authenticates to the same Azure ADB2C instance and it uses a silent authentication process to automatically log the user in if they are already authenticated.
That is the experience I want but can't figure out how to do that in Blazor WebAssembly.
I read about using possibly using an MSAL.js library (MSAL with Azure AD B2C and Single Sign On) but I can't find good docs on how to do it with standard Blazor WebAssembly.
Does anyone know how to do this?
I have .net web site which designed for working as standalone application. Due to one issue I was made to perform login flow to Facebook manually instead of calling FB.login(from FB javascript sdk). And because of this I am not able to call FB.logout (because in this case another issue appears).
Facebook support advised me this:
"In this case, you should manually clear the user's logged in session, by clearing any stored cookies, or removing any access tokens or user information stored on our end. You can refer to this page for more information on building login/logout flows manually: https://developers.facebook.com/docs/facebook-login/manually-build-a-login-flow/#logout"
I didn't get this answer. How to realize manually logout workflow?
And I didn't find any examples.
You can check what the PHP SDK’s getLogoutUrl method does here, https://github.com/facebook/php-graph-sdk/blob/5d0c4865e80e231d48a4571841bd018828fe58e1/src/Facebook/Helpers/FacebookRedirectLoginHelper.php#L156
Basically it just calls https://www.facebook.com/logout.php with two parameters:
next is the redirect URI the user should be redirected back to after logout; it needs to be within your app domain
access_token is the valid user access token for the current user of your app
My user flow is as follows...
User requests a protected resource.
User redirected to authentication provider (e.g. Google)
User redirect back to ASP.Net MVC application which uses cookie authentication.
This works great, and following the MVC sample application from the IdentityServer samples I can see a list of claims for my user.
So the main page of my application is rendered using an MVC view, I have other resources which are authorised via resource authorisation and this works great.
The next part of my application is an API. Let's say it's api.domain.com/stockquote
This should only be useable by authorised users of my application and not publically available.
I have successfully made an Angular JS application with Identity Server and understand that when the token is returned I am able to get the value of /id_token from the URI, store it in localstorage and then use it to form an authorisation header for the API e.g. Authorization=Bearer {token} . Again works nicely.
However, now I am authenticated into my MVC application how do I get this token and put it into local storage so that I can create a header for my API calls?
Can I extract it from the cookie somehow?
Is it a good idea to output it in the HTML stream so that JS can pick it up and put into localstorage (guessing now).
Can I use the token endpoint to somehow get this token?
One way to handle this might be to change the way you authenticate. Instead of handling the callback in MVC on the server side, handle it in JavaScript. Then the token is available for you to store in local storage. This might not be possible if you are making requests on the server side that uses the token as well.
I'm trying to create a server side access to a user's Facebook resources (photos/albums/etc).
I want that the user will authenticate once using its native mobile application, and that the server will be able to access user's data without the user interaction.
I'm trying to understand the steps I need to take in order to make it work.
I've read Facebook's: Login for Server-side Apps but I can't understand how to use the scenario proposed in there - because my server has nothing to do with user interaction (I cannot redirect the user to some login dialog) - the server is performing its own operation in the background whether the user is using its mobile application or not. What should I do upon token expiration for example?
More then that, I want that the user will be able to perform direct Facebook operation on the mobile itself, without the server intervention.
As I see it, this is the flow I would expect:
User's launches a native mobile application.
The user authenticates using Facebook's SDK on the native mobile app.
The user received a special token, that can be converted at server side to an access-token.
The token will be sent to the server and stored there.
If the server needs to access user's Facebook data, it uses this special token and converts it to an access token.
When the token expires - the server can extend it, using the special token, without any user interaction.
What data should be sent to the server from the mobile application after authentication. And how should the server use this data to access user's Facebook resources anytime?
I'm using the C# Facebook SDK for the server. But I think it is not that important, I need to understand the mechanics.
Tokens expire if the user does not continue to use the application. This is by design--an application should not continue to access the user's account if the user stops using the application.
When a user logs into your application, a token is given to your application, along with an expiration date for that token. You can use that token from your client or your server until it expires. However, there is nothing your server can do to extend the token if the user does not continue to use your application.
If the user continues to use your application, you will have an opportunity to update your server token. For example, in the Android and iOS SDKs, tokens are automatically refreshed if the user uses your application to make a facebook request. At that time, you can transmit the refreshed token to your server.
I am trying to implement a oauth authentication in a gwt application.
In this, initially a login page is shown- here the user chooses his oauth provider, then some data is stored in session and user is redirected to the oauth provider. After login, he is sent back to another page within the same GWT application.
That is how I want the flow to be, but I am confused about the data stored in session- the data stored before the user went to oauth provider's website, will that still be accessible after the user is sent back, post successful login? Are there any conditions/catches in storing data in session, in a GWT application, that will affect the above scenario?
If your server side is java, everything in GWT is a servlet so there's really no difference in how GWT works. Session has an expiry time once session is created it will be visible within whole application.
If third party page to your site redirection performs within session provided time.All the data you have stored in the session will be visible to you.