Xero SDK is allow to access for 30 mins - xero-api

I Created a public app in Xero and integrate it in my .net MVC application using XERO SDK,
While i Connect to xero it allow me only for 30 mins, after that authentication token got expire. How can I manage it without expire time?

Afraid you can't. As mentioned on the doc - https://developer.xero.com/documentation/auth-and-limits/public-applications - access token on Public application expire after 30 minutes.
You need to use other application types - https://developer.xero.com/documentation/getting-started/api-application-types

Related

How can I use WSO2 API Manager to store user accounts upon sign-up on my app, and use it for token generation?

How can a app (or microservice) talk to the API manager instance to create user account and generate JWT?
I have tried the WSO2 APIM and Istio integration (https://github.com/wso2/istio-apim#istio-mixer-adapter-for-wso2-api-manager). However, I find this way as developer access.
If you are using the latest version of the WSO2 APIM (2.6.0), Then at the time you create the application you could specify the type of token as JWT and get the JWT token.
enter image description here
But the use of this JWT is limited for the micro gateway for the time being.

asp.net 5 and IdentityServer4

I am working on a prototype for a site re-architecture using ASP.NET 5 and I am debating using IdentityServer4 for my Authentication and Authorization. I have reviewed a lot of samples and articles about setting up IdentityServer3 and 4 and I am trying to wrap my head around if it can handle my client’s requirements in a proper way. Here are my requirements.
I have 3 sites that need authorization. Site 1 (abc.com) will require windows authentication and will be a combination of mvc and webapi calls using roles (or roles converted to claims) for authorization. Site 2 (def.com) is a trusted site that wants a login widget with a username/password/rememberme text box on their site that when submitted will authenticate the user and redirect them to site 3 (xyz.com). Site 3 will also have its own login page and will be a combination of mvc and webapi calls using claims. Site 2 and 3 will not be using windows authentication and the client does not want them redirecting to the identity server login screen, but rather having their own login screen and calling the identity server from code with the credentials to login.
Here are my questions regarding this scenario and IdentityServer4.
Can Idsvr4 handle one client using windows authentication and
another using username/password authentication?
If so, is there a
reason to have windows auth in idsvr4 or should it just use standard
windows auth within the webapp?
Can idsvr4 be setup to have the client collect the username/password/rememberme values and pass them through code to
get the proper jwt tokens for both mvc and webapi?
If so, can it
log them into both the mvc and webapi applications on another site?
If so, is this circumventing the real purpose of identityserver4
and therefor is a bad idea?
If it can handle this scenario and is a good idea, how would I setup the client, scopes and code to handle the login through code and redirect?
Examples are great and very welcome, but I am not even sure what verbiage to use to search for this scenario so even pointing me in the right direction would be of great help.
Not sure if this question is still active. But yes, i believe you can do all that.
1) You can setup which ldp is available for each client by setting IdentityProviderRestrictions on the client (docs)
1.1) - Not sure what you mean, i believe one of the points of having idsrv is to sentralize you authentication, and it makes it easier for future websites to integrate with the same service.
2) When logging in using a client (application), you also specify which apiResource the client has access to - and the application needs to add this to the requested scopes when signing in. So if your client is the mvc application, you just add the ApiResource in the AllowedScopes - and set the request_type to id_token code - this would then give the user a access_token that is passed with each request to the backend api. (docs)
2.1) - This would basically log the user in on both sites - using an access token that says that the user is authorized to use the backend api.
2.2) - In my opinion this flow is one of the things that makes idsrv great - and they even mention this as a great feature of idsrv themself. You just need 1 trip to the authserver to gain access to all systems.
as for pt. 3 - Take an extra look at the docs, try to setup a blank project following the quickstarts.
For logging in from your own login page, you need to use the grant type Resource Owner password - Altough they dont recommend doing this for security issues (transmitting passwords over the wire) - it is supported.

When do SharePoint Online authentication tokens expire?

I have a C# app which modifies files in SharePoint Online document libraries. The app authenticates with SharePoint Online using web requests and uses the returned cookies when calling web services. The app can run for several days (possibly even weeks for large file sets) as it churns through files. Do I need to worry about authentication tokens expiring once authentication is successful and the app is running?
This article mentions the session will timeout after 5 days of inactivity, but what if my app is still active?

Persist Authentication in Web App with Power BI

I have a web app that is using the Power BI Web API to display some dashboard data, inside another application. I have followed the authentication examples on GitHub, and can authenticate and query the API.
HOWEVER, all of the examples store the returned tokens in temporary storage (e.g. session), which means that the user has to re-authenticate the application every time they visit (or the app pool restarts).
Ideally, I want to authenticate the web app when it's set up (using a set of credentials set up just for the app), and then have the web app continue to use the same credentials, without the site users having to log back in to Power BI again (as many of the users of the web app do not have direct Power BI access).
Is this possible? If so, how might I go about it? All of the examples I can find are such that you have to re-authenticate every time you access the API. I suspect because I don't know the correct terminology here (this is my first time using the AAD services and authentication) I may be missing something obvious.
To do what you want, you need to securely store the refresh token. The call to get the initial token should return both the accessToken (that expires within 1hr usually) and a refreshToken that you can use to get new accessToken. The refreshToken is usually valid for 90 days, so your access is not indefinitely. There's documentation on MSDN for how to do that:
https://msdn.microsoft.com/en-us/library/ff752395.aspx

Xamarin Forms, ADAL No Refresh Token

I have followed the great example on integrating ADAL and Xamarin Forms by Vittorio. I am still struggling though on how to best implement authentication in mobile applications based on Xamarin Forms.
What is the best way to authenticate a user in a mobile application base on Xamarin (forma) knowing that the user is registered in an Active Directory on premise which is synced to an Azure Active Directory? Currently I am using ADAL for that but would it perhaps be better to use Azure Mobile Services? I need a token so that I can authenticate a user in a webapi running in Azure Websites.
When I follow the example of Vittorio, I run into a problem that I don't get a refresh token from the AAD authentication call. I should not that my AAD redirects the real authentication call to an on premise ADFS server. I am not sure if that could be the problem?
for #1 you can use the ADAL sample exactly as is - the only difference is that you need to configure your app to request access to your web API and pass the API resource is when you acquire a token. See setup instructions in https://github.com/AzureADSamples/NativeClient-DotNet.
For the refresh token: ADAL used it automatically from its cache, but people often did not know/understand that and used the returned refresh token manually, doing a lot of extra work... So we are no longer returning the token in the result, but we do use it automatically whenever you call acquiretoken and the token needs renewing.