I have a Web application that uses Google authentication using clientID, secret key and redirectUrl. Now I have another application that is a Windows Form app and want Google authentication using the same clientid as the one used in the Web application. How can I do authentication in the Windows app?
There are several types of clients that you can create for accessing Google's authentication server.
web browser applications
native (other) applications
service accounts
mobile
Each type of client uses a different set of credentials and in some cases a different grant type. For security reasons they are designed for use with the type of client that will be used to access it.
A web browser client is requires a redirect uri so that the authorization server knows were to return the credentials to. A native installed application does not require a redirect uri because the authorization server knows to return the authorization to the same place that the call came from.
Answer: You can't use a web browser client in an installed application. You will need to create a native (other) type of client in your project and use that.
Related
I have a RESTful API which is running in a Linux docker image on AWS ECS. This API needs to be called by a desktop application (C# fat client deployed via ClickOnce) which is using Windows authentication to identify the users.
Currently although it's behind our firewall I can't identify users who call the API. I looked into OIDC but it's not an option because it requires a redirect URI to callback with the access_token which can't really happen on a desktop application.
How can I identify the users who are calling the API from their desktop app and validate they have the correct group claim which would grant them access when calling the API?
In terms of considering OIDC as an option; depending upon your set-up, I would have thought that you should be able to embed a browser (/WebView) like User-Agent within your desktop app, that can then/finally pass-back the resulting OIDC info/tokens, back to the/your hosting/underlying app (?).
Let's say I have an installed app, a console app for example, not a web app, that I want to interact with the QBO API - I want to perform calls to QBO from my console app (but not from a web application). So I must authenticate from the console app, make a call and output in the console.
All QBO SDKs seem to ask for a callback URL or a redirect URL, i.e. a page on my server, that will perform the required leg of the OAuth 2.0 authentication. As my installed app is not a webserver, I don't have a place to host this logic. Yes, I can host a webserver to handle this logic, but I don't want to do it, this is a waste of resources for my use case (why leave an auth server on standby?). I just want to authenticate without a webserver with QBO API. Is this possible? Have I messed up my understanding of the API or of OAuth? I am at a total loss. In none of the sample code I can find a suitable example despite this being the use case that I have. (I am working with .NET / C#)
It appears that at the moment the QuickBooks Developer platform will not accommodate this (non web End-Point).
As per Intuit:
These URIs handle responses from the OAuth 2.0 server and are called
after the user authorizes the connection. URIs in this list are the
only ones to which the authorization response can be sent from the
OAuth 2.0 server. You must define at least one URI specifically for
your application's auth endpoint before you can use OAuth 2.0.
Additionally they add in a note:
Mobile- or desktop-based apps that implement OAuth 2.0 must provide a
separate SaaS layer for the Redirect URI to handle responses from the
OAuth 2.0 server.
I realize this is not what you had hoped for. Please understand, however, understand that the end-point must be a URL so as to securely return the authentication token.
Ok, I have this scenario.
I have one WEB API which will provide functionality to an intranet application, the idea is this application WILL not be visible to the outside world, so it wont have a login page.
However, the web api will also be consumed by mobile apps outside the organization, so the webapi WILL be exposed via a public url.
How can I make the authentication/authorization here to support both scenarios?
1. Internal users will be able to consume the web api via the angular backend app without an explicit login page.
2. External users via the mobile app will consume the web api with their active directory account.
I found this:
https://stormpath.com/blog/token-authentication-asp-net-core
where I could easily replace the GetIdentity Method to go to Active Directory and check if user exists with that user and password, but on the intranet, I wont have that info.
ideas please?
The best way to handle such a scenario is to use HMAC Authentication as discussed here. This will allow easier access to the piblic endpoint without requirering some kind of a login from the mobile clients, while at the same time enabling you to know which mobile is acceessing your endpoint. This is the same workflow as implemented in External Auth services like login with google and facebook where you are given an apikey and a apisecret
YOU CAN FIND THE SOURCE CODE OF THE EXAMPLE USING ASP.NET HERE
I develop a native android application that done it's authentication, authorization, getting resources using WebApi backend.
After many discussions about what is the best and secure way to implement authentication and authorization using .NET technologies we decided to use Thinktecture's IdentityServer3.
Before i was follow this series to implement a token based authentication using Asp.NET Identity system, every thing was OK but after investigations i decide to decouple the authentication server and using Thinktecture's Identity Server.
So now i have a separated web apps hosted on azure one for resources and other for authentication using IdentityServer3 and one native Android client .
My Android client application having an authentication using Facebook/Google, and i already implemented this before on android using Parse or separatly based on Facebook Android SDK & Google services
Also Users having roles.
Now i want to know if there is a correct approach for doing that from the authentication server perspective and also client android application perspective as there are many discussions about the configurations of identityserver3 with native apps also should i use a webview activity in android to handle connection with authentication server or using native java code with HTTP library like retrofit to send request and get response.
Also with Facebook, i already implemented authentication directly from android app using Facebook Android SDK and i can get the AuthToken and the approach that i think about is like shown in this question:
Authenticate user to Facebook from Android application.
Get the FB auth token to the android app.
Forward the authentication token & facebook UID from Android to web
server.
On web server, make Facebook API call with the submitted token.
If the Facebook API call from web server returns valid authentication, and the user id is equal to the one submitted by Android application, your server can trust the id (& you can be sure that the Android authentication real)
Or should i depend only on backend identityserver to handle Facebook authentication?
you can use the hybrid flow (if you need access tokens and refresh tokens)
, also You could use the implicit flow
just have alook at this topic
and about how can you do it,
Either, you can do it by doing a combination of web views and hybrid/implicit flow, or do the redirect style to the IdSvr login page. Using resource owner password flow
This is what I wish to achieve:
My ASP.NET web service is hosted on a server called //service. I want to control access to the web service by server and by application as well. What I mean here is if I have two ASP.NET web applications (app1 and app2) hosted on a server called //web1 and I only want //web1/app1 to be able to call the web service. I know that I can grant access to the IP address of //web1 but that would allow both //web1/app1 and //web1/app2 access to the web service.
I am thinking about using an SSL certificate as I don't want the web application to handle the login/password. on //service, I will grant access to the ip of //web1 and map a client certificate from //web1 to a windows account and this will allow only applications from //web1 to access. But then how do I further control the access to only //web1/app1?
You can use standard HTTP Authentication to control which applications have access to your web service.
Credentials are passed in the Authorization header with each request. Every web service client (i.e. //web1/app1) should have its own credentials, so if //web1/app2 tried to connect to the web service without providing recognized credentials, it would be denied access.
I recommend using SSL to encrypt all traffic, so that authentication information and other sensitive data is secure.
Here are a few articles that may be helpful:
HTTP Security and ASP.NET Web Services (see Authentication section)
Authentication in ASP.NET Web Services
Good luck!
Not really.
A certificate secures the transmission between the client and server domain. It doesn't really work to have multiple certificates for multiple subdirectories.
What you'd want to do is to create a login service that returns a token. You then use that token to manage the session on the server side and the client uses it along with every subsequent request to access and execute the available services. (can this token access this webservice? t/f)
You're going to have to give the client access to some sort of credentials. Whether that is a certificate exchange or a user/pass you're going to have to figure out who the client actually is.