I have SPA app, backend is ruby on rails and frontend is React. Now I am developing new authentication feature; login with GitHub account with omuniauth gem.
However after authorization with GitHub we need to redirect to backend server as that is the server which is sending authorization request to GitHub authentication server. That means my frontend cannot receive response from GitHub which contains auth information such as user name, token, etc.
I understand we can redirect to frontend URL through backend API, but even in that case I believe auth information from GitHub is not passed to frontend.
Is there any way to share the auth info from GitHub after oauth2 authorization? Any help would be really appreciated. Thank you so much in advance!
For your use case (which is implicit grant flow) I think that's not possible, common pattern to solve this is token handler pattern
Basically, after your backend receive callback from the github & exchange it with access token, you can issue a cookie or token (not oauth token) to the frontend. This cookie is associated with the github's access token.
Later, after you redirected back to the frontend, you need to request the github's user profile proxied via backend
If you want to be able to access github api directly from the frontend, consider using client credential flow (typically used for SPA, without backend)
Related
I am reading and reading, not sure why it's so hard to properly understand OAuth2 flows, which I thought I understand, until I wanted my own server.
So I have Frontend (web + mobile app aka resource owner), my own API server ( resource server )
and I want to create my own OAuth2 server.
So assuming, that on user registration, I am registering them on my OAuth2 server, saving username and hashed password ( I also want to save organization/project name, so I can user oauth2 server for multiple projects without worry of username duplicates)
Then Frontend obtains access+refresh tokens from OAuth2 server directly with password_grant. Or should I do it through my API and use CLIENT_ID/CLIENT_SERCRET with it (is that even an option)?
With access token, Frontend then now can communicate do my API(resource server)
API (resource server) then communicates with OAuth2 to validate access token - here I am not sure what's the common name of that action authorize or authenticate ?
Once access token is expired, Frontend (resource owner) can communicate directly to OAuth2 to obtain new access and refresh token. Or again - it should go through API and do it with CLIENT_ID/SECRET ?
Currently I did above implementation, but inside my API, but idea of OAuth2 is that it is separated server. Not sure how it will benefit me other than I will be able to use it for other project, but I guess with OAuth2 I can then expose API to public.
Question is, is above correct ? can someone help me wrap it with correct OAuth2 terminology ?
The frontend apps are not resource owners, but clients. Resource owners are users of these apps. These apps are so called public clients - they don't have a secure storage for their client secret, so they must not have a client secret. Instead, they should use PKCE (kind of one-time password) with the the auth code flow.
This way, they receive a refresh token they can use to get valid access tokens. The frontend apps use access tokens to authorize their requests to your backend. Your backend should validate them.
For more info, please see the current best practices - OAuth 2.0 for Browser-Based Apps and OAuth 2.0 for Native Apps.
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
If I authenticate with OpenID connect, I can authenticate my SPA ok.
How do I use the obtained access token now to access my own REST resources?
It's a simple question, but I don't find satisfactory answers.
A prominent answer I always find is 'use oidc when you don't have a backend'.
Now that makes me wonder if ever a webapp was created that didn't need a backend.
Oidc is almost always the answer when the question of storing a refresh token in the client pops up (like in 'use oidc, it's a better architecture and ditch the refresh token') but it doesn't really explain anything.
So when the user logs in with, say Google, he obtains an identity and an access token (to ensure that the user is who he claims he is).
So how do you use this to authenticate at your own REST service?
The only real way I see it as stateless is by sending another request at the server to the provider on every request to the REST api, to match the identity to the validity of the access token there.
If not, we fall back to the good 'ol session vs jwt discussion, which doesn't quite seem to click with the oidc because now we're duplicating authentication logic.
And the good 'ol refresh token in the browser is generally promoted as a bad idea, although you can keep access tokens in the browser session storage (according to the js oidc client library), autorefresh them with the provider and that's fine then (-.-).
I'm running again circles.
Anybody can lay this out for me and please break the loop?
Your SPA (frontend) needs to add an authorization header with access token to each API request. Frontend should implement the authorization code flow + PKCE (implicit flow is not recommended anymore) + it needs to refresh access token.
Your API (backend) needs to implement OIDC (or you can use "oidc auth" proxy in front of backend) - it just validates access token, eventually returns 401 (Unauthorized) for request with invalid/expired/... token. This token validation is stateless, because it needs only public key(s) to verify token signature + current timestamp. Public keys are usually downloaded when backends is starting from OIDC discovery URL, so they doesn't need to be redownloaded during every backend request.
BTW: refresh token in the browser is bad idea, because refresh token is equivalent of your own credentials
I've created a FeathersJS backend app and a React frontend app. I'm using OAuth2 strategy to authenticate users to my own WordPress site. Everything is working fine. But now I'd like the users to be able to access my FeathersJS backend REST API, but as they authenticate through the WordPress OAuth2 server, thus following all the OAuth2 authentication process through my React frontend app, which would be the correct FeathersJS way to allow the users authenticate to my backend so that they can do REST API calls?
But now I'd like the users to be able to access my FeathersJS backend REST API
To let people access your backend REST API (which I assume is only possible after they authenticate), you need to check whether the access token they have is, in fact, valid with the third party auth provider.
You can directly let them use the back end API. In case the API doesn't find a valid access token with the incoming request, it will redirect it to the login page. After which, now the backend can validate itself with third-party OAuth provider and return the result.
following all the OAuth2 authentication process through my React frontend app
It is recommended to not do all the OAuth check from front-end since this exposes the access-token on the user agent, which might be a serious issue. See this:
https://www.digitalocean.com/community/tutorials/an-introduction-to-oauth-2#grant-type-implicit
My API uses the devise_token_auth (omniauth) gem for authentication in the Rails 5 backend. The frontend are using ng-token-auth (Angular 1.x).
I have all the API requests in Postman. I did the security implementation and I need authenticate Postman with every request. Devise_token_auth uses authentication with OAuth 2 and I am having difficulty to implementing this authentication.
For this type of authentication, using Postman, what is the process needed to obtain the connection?
For getting the token, there are few things you need to setup.
The client ID, client Secret are the things to be added into your identity serve as clients.
The Auth Url and access token url will be provided by the identity server and you will be able to get the url by hitting the identity server website when its ready for testing.
The grant type also is dependent upon how you setup the client. For the first time try doing the access token instead of authorization code flow.
For the authorization code flow its a two step process. Get the code first and use the code to get the token.
I recomment watching this tutorial which will help you in understanding Identity server and oauth better.
https://app.pluralsight.com/library/courses/oauth2-openid-connect-angular-aspdotnet/table-of-contents