I am using C# Web API and the Microsoft OWIN OAuth Namespace to grant a user an access token when they have successfully authenticated. When they authenticate, I also set up some caching of user related information.
I'm trying to determine a way to determine when a user's access token will expire, so that I can invalidate and clear the server side cache for that user.
What is the accepted way to do this using token authentication?
You can create a cron job for database as a turn to clean database.
Cron job for linux base.
Scheduled Task for windows.
Related
I have an application which is sitting behind WAF (Web Application Firewall).
Application is using Microsoft Active Directory for authentication.
Here are the steps
User try to access the application using the browser.
WAF layers see that REQUEST is not authenticated, hence forward it to Azure Active Directory
AAD shows the login page and the user enters username/password/MFA
Now token from AAD send back to the browser and it will be sent to the backend application
Now question is,
How backend application verify this token? Does it need an outbound connection to AAD or will it talk to AAD through WAF and browser?
Do I need to have NSG rules (outbound ) to talk with AAD?
It depends on which auth flow you are using.
For Authorization code flow, your application would need to talk to AAD to redeem auth code for access token and refresh token via back channel. So, you would need to allow connection to AAD (login.microsoftonline.com).
For Implicit grant flow, it's browser which directly gets access token from AAD via front channel. So, in that case, you won't need whitelisting in backend WAF.
I have resolved the issue by using service tag feature in NSG. Backend application need to be able to reach AAD in order to validate the access token.
I have added outbound rule with Destination Service Tag Azure Active Directory as shown below.
Here is the link: https://learn.microsoft.com/en-us/azure/virtual-network/service-tags-overview
I have a .net core web API server that I connect to from a mobile application. The server creates an invoice on Xero and sends the user an email etc...
I have been using oAuth 1 with no issues, but now need to switch to oAuth 2. As there is no front end-user on the API server, can this still be accomplished?
All the documentation I read, seems to need a manual login to grant authorization and get an access token?
I was using the XeroApi settings in my appsettings.json file with a pfx certificate and a private app.
I am using the C# SDK
Thanks in advance :-)
You'll need a user from the Xero organisation to go through the OAuth2.0 flow at least once to retrieve an access token. If you request the offline_access scope during this flow, you'll receive a refresh token as well; this will enable you to refresh the access token from your web server on an ongoing basis, without user intervention.
So yep, you'll need a manual login at least once, but as long as you request & retain the refresh token from that initial flow, once should be enough.
I have a local server exposing an api that let clients to interface with some azure APIs such as azure ressource manager .
The authentication is done using the Microsoft.IdentityModel.Clients.ActiveDirectory nugget package. I get a token and use that token to make requests to those APIs.
The problem is that this token expires after after a certain period and the clients can no more access azure APIs services through the local server.
Is there a way or best practice that allows the local server to automatically reauthenticate or acquire a new token.
The goal is to automate this such as connectivity with azure api is available all the time for consumption through the local server.
Any help or guidance will be very appreciated.
As far as I know, there is no way to automatically reauthenticate or acquire a new token when the previous token expires. When the token expires, you could use refresh_token to get a new token. Or you could Configurable token lifetimes, the maximum for the access_token lifetime is 1 day. For the details about configuring token lifetime, you could refer to here.
I am trying to better understand the OpenID Connect protocol with IdentityServer4, and am unclear on where I can find the answer to this question.
I like the idea of the Identity Server providing a Bearer Token at the end of authentication that includes claims on who the user is, and what resources they can access. However, I am a little uncomfortable in storing what Resources a user may have access to within the Identity Server environment. I would like this Authorization piece to be authored at my client application. Is there any type of callback in the OpenID callback that allows IdentityServer to call the client and request Authorization Claims from the client directly, rather than piece it together directly?
As an example, I am working on a product that will require a user to log in using either Windows Authentication, Username/Password, or a Google Account.
This client application will be hosted in a cloud environment, and will be hosted in the same domain as the Active Directory Server.
My thought was to create an Identity Server solution that is hosted internally, and to create a Client application that is hosted in the cloud.
When the user logs into the Client application, they would be redirected to the Identity Server to log in. The Identity Server would be hosted in the same domain as the Active Directory Server, so if there were Windows Credentials we could log them in automatically. Otherwise, there will be a login screen where they can enter a Username/Password, log in with Google, etc.
Once the user has logged in, the Identity Server would return a Bearer Token (a JWT probably), that has their claim information.
I can foresee this one Identity Server being used by many different Client application, because it would intrinsically allow Windows Authentication. For this reason, I am hesitant to store all of the API Resources the user can access within the Identity Server itself. My fear is that if I add a new permission to my client application (like a Report Admin claim), I would need to modify the Identity Server to include that new claim. And if 4 or 5 clients all use this Identity Server, this could get to be a bit onerous.
Instead, I would like to structure Identity Server so that when a user logs in for a particular client, Identity Server will make a callback request to the Client Application asking for the Claims that apply to that user. That way, the Client Application knows and cares about the User/Claim mappings, not the Identity Server. If I need to add a new Claim, I can do that within the Client application. If I need to map a user to a Claim, I can do that on the Client application. I don't need to do this on the Identity Server.
Is this functionality that already exists? If so, what do I need to be looking for? From what I can tell, it appears that the mapping between the User and the Resources they have access to all occur on the Identity Server.
The guide I am following is this: http://docs.identityserver.io/en/release/quickstarts/1_client_credentials.html#defining-the-api
Thank you for any guidance.
The Identity claims are not supposed to be used for Authorization, in fact Authentication and Authorization are two totally different concerns.
I'd suggest you watch this video which explains why and also provides an alternative PolicyServer that would answer your questions (great talk from the developers of IdentityServer).
I want my web server code (invoked from ASP.NET MVC3 site's controller) to be able to save files to Dropbox account.
I have examined two out of three .Net/Dropbox libraries and all of them require a user to "authenticate" via web-redirect to Dropbox to get a token.
Examined libs are Spring.Social.Dropbox and DropNet.
Can this authentication and upload be done via purely .net code without messing with the user's browser? Can the acquired token be saved for later use? This is theoretical question, not about particular implementation.
This is a bit of a complicated subject. As far as I know Dropbox uses OAuth, which is an authentication and authorization protocol.
General process is this:
You create authorization request token
User gets redirected, authenticates and grants permissions to your app.
You trade the request token for an access token
You must save the access token because it is used to perform actions on the users behalf
Access tokens don't usually expire and only stop working if a user revokes your application permissions.
This means the user will have to authenticate and authorize your application at least once so you can get the access token and access token secret.
After that, you are pretty much free to perform actions on the users' behalf based on the permissions granted. You must specify the access token attained by the above-mentioned process in order to perform actions.
In short, get an access token, save it, use it for requests.
Does this clarify it a bit for you?