I have a authorization server which generates and store bearer tokens for username and password log in using the oauth2 password grant. I want to integrate social sign in (Google and facebook) to my existing authorization server. Since my other resources are protected by authorization server how do I generate a Bearer tokens for google/facebook signed in users ? so i can access my protected resources using that token.
Note: Bearer tokens are stored in mysql db. (Using JdbcTokenStore)
Since I already have password grant implementation, I'am glad if you can give me direction to do with the current authorization service using spring-boot and spring security.
Thank you.
There are 2 main ways to implement this:
Federation, so that the Authorization Server manages integration with social identity providers
Handle different providers in your apps, which will add complexity to both your UIs and APIs
Personally I much prefer the first option, which only requires configuration changes - and no code changes in UIs and APIs. My Federated Logins Blog Post may help you to understand your architectural choices.
It is worth doing some early technical testing to see if these steps work:
Adding an OAuth web client to Google / Facebook
Adding an Identity Provider to your Authorization Server
Related
I have an Authorization Server with Spring Security 5. It supports Authorization Code, Authorization Code with PKCE, Implicit Grant and Client Credentials flows from the OAuth 2.0 authentication framework for it's clients. This Spring Security 5 Auth Server is also connected with a database with users information and it's passwords hashing. Currently the Auth user validates users credentials from the login page using the users tables from the database.
Right now I need to setup an AWS Cognito User Pool and use the same users already stored in the database. My intention is to use the Spring Security Auth Server as an OIDC Identity Provider for my user pool in AWS Cognito.
Is this possible?
AWS Cognito can act as an Authorization Server, meaning your apps will get AWS tokens. In this case you add Spring as an OpenID Connect IDP, similar to my blog post which used Okta as an IDP. This could be quite an impactful change though, since you may not be able to make Cognito access tokens contain any custom values.
Alternatively you can do it the other way round, in which case your apps will receive Spring issued tokens. I would expect the integration to basically work, whichever way round you do it, though you could experience some annoyances.
An important factor is how your APIs / back end will identify users from access tokens after this change, since Cognito and Spring will use different subject claims in access tokens. In case relevant, this detailed Curity article discusses migrations and user IDs.
I'm struggling theese days on the possible way to configure an Authentication + authorization system to consume a REST API from a mobile application.
Scenario:
We've developed 3 independent portals for a big customer that serves several users.
To enable a SSO for the 3 portals we've implemented a SAML authentication system using SimpleSAMLphp.
Every portal has a service provider and they make assertion requests against a central IdP.
The IdP checks username and password against a database where passwords are hashed and stored during registration.
After the login, the authorization on the portals is handled by the session on the server, and so far everything was fine.
Now the customer asked us to develop a mobile application that will require the users to login and access several of their protected resources collected during the usage of the 3 portals.
We've decided to develop a frontend application using ionic that will consume a REST API made in node.js that will serve all the data (both protected and unprotected resources).
Now here comes the question: to authorize access to protected resources on the Api we'd like to use JWT to easily achieve a stateless system.
The doubt is how to perform the authentication? We've the opportunity to check the credentials directly against the database skipping the SAML process, otherwise we've to implement a solution where the SSO IdP acts as authentication provider and then when an attempt is successful the API app will get the response from the idp and then issue a signed jwt to the consumer client. Is this second way a common implementation? Is it possible?
What path do you suggest to follow? The first could be very easy to achieve, but since we're using html+js for the app's frontend, if we decide to use the second solution probably in the near future we could recycle some code from the app to modernize some functions on the web portals, maintaining the jwt pattern and consuming the new Api also on the web.
I believe that in this case will be easier to ask a token to the new api using someway the logged in user's data already in the session of the portal. Sounds possible?
I hope that everything was clear, any help will be appreciated!
Thanks
The key goal here is to code your apps in the best way, via
the latest security standards (OAuth 2.0 and Open Id Connect).
SAML is an outdated protocol that is not web / mobile / API friendly, and does not fit with modern coding models.
Sounds like you want to do OAuth but you do not have an OAuth Authorization Server, which is a key part of the solution. If you could migrate to one you would have the best future options for your apps.
OPTION 1
Use the most standard and simple option - but users have to login with a new login screen + credentials:
Mobile or Web UI uses Authorization Flow (PKCE) and redirects to an Authorization Server to sign the user in
Mobile or Web UI receives an access token after login that can be sent to the API
Access token format is most commonly a JWT that the API can validate and identify the user from
The API is not involved in the login or token issuing processes
OPTION 2
Extend option 1 to federate to your SAML Identity Provider - enables users to login in the existing way:
The Authorization Server is configured to trust your SAML based identity provider and to redirect to it during logins
The SAML idp presents a login screen and then posts a SAML token to the Authorization Server
The Authorization Server issues OAuth based tokens based on the SAML token details
OPTION 3
Use a bridging solution (not really recommended but sometimes worth considering if you have no proper authorization server - at least it gets your apps using OAuth tokens):
Mobile or Web UI uses Resource Owner Password Grant and sends credentials to a new OAuth endpoint that you develop
OAuth endpoint provides a /oauth/token endpoint to receive the request
OAuth endpoint checks the credentials against the database - or translates to a SAML request that is forwarded to the IDP
OAuth endpoint does its own issuing of JWT access tokens via a third party library (if credentials are valid)
Web or Mobile UI sends JWT access token to API
API validates received JWT access token
I'm new to OAuth 2.0 and OpenIDConnect
I want to ask if is it necessary to implement OAuth 2.0 and OpenIDConnect for our login, register flow of our own created client application (mobile apps and server side app)?
Because I've been searching tutorial to implement login, register flow the best practice right now is using OAuth 2.0 and OpenIDConnect but their implementation is toward to securing our API against other people client application. Is this auth flow is just used to secure another people client application to access our API?
Thank you
OAuth 2.0 is both elegantly simple or extremely complex depending on your understanding of the technology and how to implement authorization.
I'm new to OAuth 2.0 and OpenIDConnect I want to ask if is it
necessary to implement OAuth 2.0 and OpenIDConnect for our login,
register flow of our own created client application (mobile apps and
server side app)?
No, it is not necessary to implement. There are many methods of authentication and authorization. OAuth is just one of the more popular methods.
A simpler and terrible method is to just implement username and passwords for your users. Simpler, in this case, is a relative term as now you need to worry about keeping usernames and passwords stored somewhere securely.
OAuth can be used to secure public access to your website, applications (REST endpoints), and more. OAuth can be used for server to server authorization. In the end, OAuth is just a method of creating a token that is presented to a service. The service verifies the access rights of that token and denies or proceeds with the request.
Authorization and Authentication are domains that require a lot of experience to implement correctly. There are many nuances to consider. That is why so many companies are breached, they do it wrong or implement weak methods. At one company I visited for an audit, I wrote down 10 usernames and passwords because everyone had yellow postit notes on their monitors. Even the best OAuth implementation will have problems with that level of security.
i'm implementing a REST layer for an existing application. I have my userid and passwords stored in database and i would like to authenticate these credentials while calling my REST services. Note that this is a standalone application.
After investigation, I figured out 2 ways.
Basic implementation with HTTPS - this approach makes sure that
userid and password passed is not tampered by Man in middle attack.
Using Authentication Token(JWT) - user initially passes his userid
and password and server gives back an Authentication token.Once user
have an authentication token that could be used for subsequent
request.
Using OAuth 2.0 - I'm very confused in this approach. After reading the docs and specification, I found that since my application
is standalone, I need to implement Authorization Server, Resource
Server etc.
I'm asked to implement OAuth here, but i'm not convinced that OAuth is required in this scenario. I'm more inclined towards just implementing JWT(tokens)
Is OAuth really mandated in this scenario. What i understand about OAuth is it is used when you already have a service like Facebook/ Google.
Could someone pls confirm if my train of thoughts are correct and if OAuth 2.0 is required in this case?
The primary goal of OAuth 2.0 is to allow users to authenticate to use a client application via a third-party authentication provider (e.g. Google, Facebook, etc.), without exposing their credentials (typically a username/password) to the client.
In your case, if users are only ever going to authenticate to your system using their credentials in your database, then implementing OAuth 2.0 doesn't add any substantial value for you.
The OAuth 2.0 specification does define a "Resource Owner Password Credentials grant", intended for legacy use cases, that would apply to your situation: a user sends credentials, and you return an access token (that could be a JWT, if you like). If it's desirable from a management or marketing perspective, you could implement the Resource Owner Password Credentials grant and legitimately state that your application "conforms to a subset of OAuth2, as defined by RFC6749".
I am new to security domain, so don't know whether this question is valid to be asked here. I am currently using OpenAM for the security of my web application with J2ee agent, now I find that OpenAM can do authorization with OAUTH as well as on the basis policies defined, now both openam and oauth develops tokens for valid users, and do not share user credential with the application, so how different are the two? My second question is if my application does not support oauth like google and facebook what basic things I need to do to implement oauth into my application.
OpenAM supports OAuth based authorization if that is what your confusion is about. It also supports
1) OpenID Connect
2) SAML
Your application can use either of these to get authorization from OpenAM. Your application can also use the REST APIs for this purpose. The choice is yours.
As far as the tokens go, OAuth tokens are different from OpenAM Tokens. OAuth tokens include
1) refresh_token
2) access_token
The access_token is used for making oauth based calls. However, OpenAM tokens are basically what is there in the cookie or what you get via the REST API.
Regarding your second question, to support OAuth, you would need to use a oauth client library and enable oauth on the server side (in this case OpenAM). This client library would be dependent on the language you choose to write this application.