I am trying to integrate the Google Sign-in mechanism with OpenID Connect into my web application. The app has a Rails frontend just for rendering the web pages and it is connected to a backend written in Erlang. I will use the Google Sign-in Button but I want to centralize the Authentication in the backend, so that I could Authenticate users and also protect the backend API either using the Rails frontend or via cURL.
Therefore, I found this library https://github.com/ianbarber/Erlang-GoogleApis-Example/ that seems to be useful for calling the Google API, and if it is possible to authenticate, fetch the user's data, store it into the database, send the response to Rails and then the frontend will render the website.
The questions I have are the following:
In order to protect the Backend API, should I allow only POST requests that include in the headers the Access_Token or ID_Token given by Google? Or is this still not enough?
There are two other servers who need to perform certain POST operations. Only they should able to do those requests. How can I establish different levels of authorization for them? Because users shouldn't perform those API calls.
I saw there are other approaches such as generating an API_KEY and API_SECRET_KEY but my boss don't want me to use such approach, so maybe with OpenID Connect I can carry out the authentication of users, but also the protection of the whole API.
Thanks in advance.
Related
I'm having the following scenario:
A frontend SPA based on Vue.
A Nest.js-Application providing an API
The user should authenticate against the Nest.js Application with Azure AD.
The Nest.js Application should provides several Endpoints where other Apis (e.g LinkedIn or Graph) should be consumed.
My Question now is if this scenario is realizable and if yes how do I have to implement the Authentication for the External Apis which are consumed by the Nest-Application?
Many thanks in advance
If I understand you correctly, you want users to be able to authenticate with Azure AD, LinkedIn e.t.c. for LinkedIn you can use http://www.passportjs.org/packages/passport-linkedin-oauth2/, the goal is to get a token that contains the user's information after authorization with these external APIs on the backend, you have to set a URL on the backend that points to the frontend with the token appended, on the frontend, you need to provide the callback URL, get the token from the URL, then you do a redirect.
I’d like to use the Google Cloud App Engine to serve a SPA and a REST API, both secured behind an authentication wall.
Is there any recommended way of doing this?
So far, I’ve found tutorials on how to secure an API, but not an SPA. Both ends are served from different projects, but I’d like to have a unique authentication step.
Typical flow would be:
Before serving the SPA source code, ask for authentication
Once authenticated, serve the SPA and allow the SPA to access the API resources
Thank you!
So far I’ve reviewed the documentation, it doesn't seem like there is any specific recommended way to authenticate an SPA within Google Cloud.
However, I think a pretty secure way would be to authenticate your application using the Toolkit Identity API of Google. The procedure would be to call this API from App Engine as the first necessary requirement.
This method works with Oauth2 access tokens. I think you could request for authentication credentials to your users before launching your application and granting access to the other resources/APIs.
Iam a student and i making my internship. Sorry for my bad englis
The situation
2 people are building an backend for an message system. There are actual and passed messages. The main backend contains all the data from all the messages. This backend pushes only actual messages to and database from an mini backend which only contains the actual alerts. These actual alerts are provided by an api to multiple front ends such as an app.
I need to do research about api gateways which can make the data in the mini backend accesable for external developers. These developers only need to register or request an account so we know which application/developer connects with our api. We don't have end users with user accounts.
The API need to be scalable because in the future (over a couple of months) this system wil replace an old system. The current system needs to be handle more then 5.000.000 requests in a couple of minutes when sending out an emergency message/alert.
My problem
I googled a lot about authentication methods and i read about OAuth2. This is only necessary for authenticate end users with an user account? I dont have that so OAuth is to complex for my situation i think. But when i look in the documentation of several API Gateways like Mulesoft, Amazon API Gateway and some more i always come back by OAuth and not by an simple authentication token system or something.
See this link and then Creating a client registration flow. This uses OAuth or do i understand this incorrectly?
So now my questions
Is there an default method such as google or facebook uses for authenticate external applications by an API key? and how is this method/framwork/idunno caled?
Is it posible that i can/need to do this with OAuth?
Some example API gateways that can fill in my wishes will be great!
Amazon Api Gateway team here.
Our service supports native API keys which satisfy simple use cases. Are you interested in a simple mechanism to authenticate clients when they access your API? Some limitations would be that it's harder to manage a large number of keys, and there wouldn't really be any authorization to specific backend resources, only authentication to access the API in general.
http://docs.aws.amazon.com/apigateway/latest/developerguide/how-to-api-keys.html
OAuth is better for dynamic user bases where new users register and you want to be able to control access for existing users over time. It is also useful when users have personal data that only they should be able to access.
Jack
I am creating a mobile application which will talk to my REST Web Services, for login, GET, POST, DELETE and logout. I have been trying to figure out how to secure these REST Web Services using Keycloak. I do not want any In Browser Login on the mobile application, so I was inclined towards Direct Grant API and Admin REST API for authentication and token validations. But, now after looking at the available options on Keycloak, every request from the mobile app must be intercepted, and then make a REST call to the Keycloak module for validating the token and then return a response back to the mobile app.
Is there a better way in doing this? Some inbuilt function calls to check the token validity instead of making an HTTP call for every request from the mobile app? I think this is a huge overhead.
My server is on JBOSS. Spring, Resteasy and Keycloak-services are being used to figure out a solution for this problem.
We are designing a web service for an application that takes OpenID as an authentication option. The question came up how do we enable API access for this user at a later time?
For clarity here is an example:
1) user A visits the site and registers using Yahoo (or other) OpenID
2) at a later time we'd like to enable API access to backend synchronization apps that act on behalf of this user.
3) giving an app a key that can access all accounts everywhere is not an option for security reasons
What are examples of using patterns like that?
Standard OpenID requires a browser because it depends on being able to load a page from a foreign site to complete the signin process. Therefore it's not appropriate for server-to-server API use.
It is more common to use OAuth as an authentication mechanism for server-to-server APIs. While standard OAuth also requires a browser and a user-interactive flow to grant access to a new application, it results in a token that can then be used by the application to act on behalf of the user for user-unattended requests.
Facebook is possibly the most high-profile user of OAuth 2 for APIs, and its Login Architecture document describes the various login flows they support at a high level. The one titled "Server-side Login" is the conventional OAuth flow, while others are different approaches that support different use-cases like mobile app sign-in and access from client-side JavaScript embedded on other sites.