I am using Cognito in AWS. There are no users in the Cognito User-Pool, instead of this it is connected to a federated IDP through OpenId Connect. The federated IDP is an Microsoft ADFS.
I have another application, which is using the Cognito OpenId Connect solution for securing an web Application.
The User access the Web Applikation, is beeing redirected to the IDP Login page. He authenticates against the federated IDP, gets back to the Website and is logged in there.
Everything is fine in this scenario.
The same web application offers a REST Api, too. With this connection I have some trouble. There is no human user who is consuming this API, but I have a service account created in ADFS.
First of all I need to get the access code:
https://demo-cognito-trg.auth.eu-central-1.amazoncognito.com/oauth2/authorize?response_type=code&client_id=1************q&redirect_uri=https://my-redirect-domain/management&state=STATE&scope=openid+profile+email
From that URL I can get the authorization code and use this to get an access_token from the oauth2/token endpoint. But when I do a GET on this ressource, I get a webpage where I need to authenticate myself.
What call do I need to perform so that I can use f.e basic auth to signin my service user?
Related
I am working on a Spring Boot application (that I inherited) with a login screen that connects to a local database to check the username and credentials, then originally it called Okta authentication to match the username and password and check credentials. My client no longer wishes to use Okta and has asked me to switch to Google OAuth2.0 for User Authentication. My only question is it seems using that service forces the user to log into the application with their Google Credentials in a google login screen. Is it possible to have the users login credentials from the applications login screen log into their google account on the backend to check credentials rather than have the user themselves login twice? I know that this is a bit of a backwards approach, but due to the current infrastructure of the application (which is currently getting a face lift) this is what we need to do in the immediate.
I have been reading all of the OAuth2.0 documentation and watched a few tutorials, but cannot find anyone trying to do exactly what I am trying to do.
Summary:
I want my oauth client to re fetch the Authorities from the oauth authorisation server for every request, so any changes to the users Authorities are reflected straight away.
Details:
I have a Spring Boot web app that is secured with #EnableOauth2Sso.
I have written my own oauth authorisation app, that is secured using #EnableAuthorizationServer.
My web app is set to use the authorisation code grant type. This all works fine, and I can log in to my web app against the authorisation app, with whole oauth2 dance occurring correctly resulting in the authorisation code being swapped for an access token.
Once we have the access token back in the web app, as part of the initial authentication, spring security on the web app is then calling the /oath/check_token end point on the authorisation server and storing the returned user info in the HTTP session.
How can I stop this, and make it re request the user info from the authorisation server for every request to the web app?
I have a web application that makes use of spring security and authenticates users against an AD server using LDAP so we do not store the users password in our application. This all works fine.
Now my application is trying to make RESTful webservice calls to a sharepoint server which requires NTML authentication. The sharepoint server also authenticates users by doing an LDAP lookup to the same AD server.
Is there a way to avoid having to ask the user for their credentials again (somehow letting sharepoint know that the user has been authenticated with the use of a token or something?)
I'm developing a web application that has a REST api. At the moment the Api are protected in the server side trough spring security with a form-login authentication. Recently I also added spring social to allow access with facebook and twitter and all this works. So a user has to be registered to access some endpoint.
Now I have to build a mobile application that has to access the REST api and I was wondering what strategy I should use.
I saw that facebook has a android/ios sdk to allow the authentication on mobile side. So once theuser is authenticaded on the mobile I should do the request to my server so how should I authenticate the user on the server side to access the resources?
If you think that is not a good solution can you give me an advice how I should solve this problem?
Two options:
Your mobile app can login to your API the same way your other client code does, via form-login or spring social. Simply send the same session ID cookie with your API calls after login.
You can allow your app to accept a username and password as HTTP headers via HTTP-Basic, to save yourself the initial login step. This might be more useful if you don't need to make a lot of API calls per session.
I want to do authentication in RESTful web service for every request. I have read scope about OAuth in website.
What should I store in database or which token key or access key need to check with database? I have REST web serivce and android app to call web serivce. So, Web service is served as a Service Provider, UserLogin is user and Android application as a Consumer like describe in Oauth site. So, if user request from android like
GET /username/a.jpg HTTP/1.1
Host: localhost:8080
Authorization: OAuth realm="http://localhost/username/a.jpg",
oauth_consumer_key="dpf43f3p2l4k3l03",
oauth_token="nnch734d00sl2jdk",
oauth_nonce="kllo9940pd9333jh",
oauth_timestamp="1191242096",
oauth_signature_method="HMAC-SHA1",
oauth_version="1.0",
oauth_signature="tR3%2BTy81lMeYAr%2FFid0kMTYa%2FWM%3D"
But from server side which is web service how to check with database or which key will be use to check? is it signature?
Read up on http://oauth.net/core/1.0/ .. specifically Appendix A.2 through A.4.
It describes the "handshake" that takes place when a service fails to get access, then redirects the user to the authentication website, then is returned back to the callback url.
As you asked, in A.4, yes, the service then examines the signature and replies with an access token.