DEV Community: Sedky Abou-Shamalah

Convert REST to GraphQL With No-Code

Sedky Abou-Shamalah — Wed, 29 Dec 2021 19:15:21 +0000

REST to GraphQL magic

What would you do if you needed to turn three legacy REST services into one smart, secure and easy to manage data graph? And what would you then do with that graph?

In this article, we’ll walk you through the magic of using Universal Data Graph (UDG) to combine multiple REST services into a single graph. How you then leverage that power is entirely up to you…

Universal Data Graph in action

Imagine you have three different REST resources that you want to tie together into a single graph. In fact, don’t just imagine, work alongside this article using publicly available resources from JSON Placeholder to see how easy it is.

For the purposes of this process, we suggest using the Users resource, which returns a list of users: https://jsonplaceholder.typicode.com/users

Enter an ID and you can see a single resource. For example: https://jsonplaceholder.typicode.com/users/5/

An individual user can have posts, as you can see here: https://jsonplaceholder.typicode.com/users/5/posts Enter the URL and you’ll see a long list of posts that belong to that individual user.

The final level of this is that each post can have comments. So if you have a post with an ID of 41, you can look at https://jsonplaceholder.typicode.com/comments?postid=41 to view them.

Let the stitching begin

What if, instead of making three different calls, you stitched those three resources together? That way, you could work with a single graph call instead.

To do so, start with the Tyk Dashboard and add a new API. Call it ‘composed’ and check the ‘GraphQL’ and ‘Compose new GraphQL service’ options. Next, click ‘Configure API’ at the top right of the dashboard and select ‘Open (Keyless)*’ as your authentication mode.

Save and then click into your API to start building the schema. Click on ‘Schema.’ You won’t need a mutation, so delete that and just keep the query.

Next, add a new user type, entering the ID (ID), name (String), email (String) and username (String). There are more that you can add, but these are sufficient for demonstration purposes.

Now, change the default query into the user query, taking in ID (mark it with an exclamation mark to show its mandatory) and setting the type as a user.

That’s it in the schema editor. Now switch over to ‘data sources’ and you’ll see your user query. Data sources are required, so click on the user query and then on ‘data source’ where you can toggle the ‘define data sources’ slider.

You’ll have a couple of options when it comes to data source type. Click on ‘REST’ and enter the URL you used earlier: https://jsonplaceholder.typicode.com/users/5/

Then, instead of the ‘5’ you can use Golang templating – {{ }} – and ‘.arguments’ to access the arguments that are available in the data model. Enter ‘.id’ for the name of the argument that you made. So you should end up with a URL that reads:

https://jsonplaceholder.typicode.com/users/{{ .arguments.id }}

Choose Get as the method and click ‘Update field’ at the bottom right. And that’s it.

Time to play

Now it’s time to head to the playground within the Tyk Dashboard and write your user query, asking for the ID, name and email. You’ll need to include a user ID, so opt for 5, in line with the example we’re working on.

Hit the play symbol.

As you can see, the GraphQL resolver has taken the graph query and resolved it into the REST call to the upstream with the ID of 5.

Adding in the posts

Now, let’s tie in the posts. To see all the posts that belong to this user, head back to the schema and add in a new type, called post. Add in the user ID (ID), post ID (ID), title (String) and body (String).

The user can now have a new type, so add posts to the user types (an array of type post).

Head over to data sources again and you’ll see that the user has a new type: posts. You can now define this as a data source, so that your GraphQL resolver knows to make a REST call to this resource if you ask for a post.

Click on ‘posts’ under the user type and, in the data model section, ensure that ‘Is List’ is checked. Now, under data sources, toggle the define data sources slider and use the predefined example that you built previously:

https://jsonplaceholder.typicode.com/users/{{ .arguments.id }}

Next, add the endpoint:

https://jsonplaceholder.typicode.com/users/{{ .arguments.id }}/posts

Now, this data source doesn’t have an argument, so instead of arguments.id, you can use .object – that lets you use any of the fields that were resolved from this current data source. In this example that means you can use any of ID, name, email, username or posts. Using .id will inject the user ID into the next call:

https://jsonplaceholder.typicode.com/users/{{ .object.id }}/posts

With me so far? Great. Click ‘Update field’ and go back to the playground.

You can now add posts, including user ID, title and the ID of the posts, into your query. Hit play and you’ll see the results – all the posts that belong to user number 5, including their titles and post IDs.

Next, you can use those post IDs for the next chain: comments.

Adding in the comments

Each post can have a comment. You can see this takes an argument in the query parameter, as shown here with the post ID: https://jsonplaceholder.typicode.com/comments?postid=41

To get the comments for any post ID, head back to your schema once more and add a new type: comment, along with post ID (ID), comment ID (ID), name (String), body (String) and email (String).

Now you can modify your post type to include comments (an array of type comment).

Head over to data sources again, open up comments within the post type and toggle ‘define data sources’ in ‘data sources.’

Now, you want to make a REST call to comments with a query parameter of postid and using the ID field from the post data source, like this:

https://jsonplaceholder.typicode.com/comments?postid={{ .object.id }}/posts

Update field once again and head over to the playground, where you can now add comments to your query, including the post ID, name, email and body.

Hit play and voilà – you can now see the comments for each post.

And that’s it – that’s how easy it is to stitch three different REST resources together, combining them into a single graph.

Now it’s your turn. Where will this newfound ability take you?

Setting up AWS Appsync for unauthenticated users

Sedky Abou-Shamalah — Tue, 02 Nov 2021 19:06:05 +0000

Edit:
Here's an updated version of this blog:
https://sedkodes.com/blog/aws-appsync-for-unauthenticated-users

This took me days to get the handle of, so here's to hoping I can save anybody else the trouble.

so you want to expose some of your queries (but not all!) to public users, so that users can use/interact with your app before having to sign up. Makes sense!!

Well, it's a royal PITA.

Set your Appsync API to be protected by IAM
Create a Cognito identity pool, and create a role for unauthenticated users:
For the unauthenticated role, specifically assign the fields/types you want.

If you'd like to be confused by AWS' documentation of how to do this, start here, or here.

Alternatively, you can copy this template where I give access to two subscriptions only:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "VisualEditor0",
            "Effect": "Allow",
            "Action": "appsync:GraphQL",
            "Resource": [
                "arn:aws:appsync:*:*:apis/*/types/*/fields/onCreateOrders",
                "arn:aws:appsync:*:*:apis/*/types/*/fields/onUpdateOrders"
            ]
        }
    ]
}

Finally, in our JS code, I use the Amplify SDK, so here's how I configure that:

const config = awsRealtimeConfig: {
        aws_appsync_graphqlEndpoint: "https://<graphql-id>.appsync-api.<aws-region>.amazonaws.com/graphql",
        aws_appsync_region: "<region>",
        aws_appsync_authenticationType: 'AWS_IAM',
        Auth: {
            identityPoolId: 'us-east-2:pool-id-here',
            region: 'us-east-2',
        }
    },

Amplify.configure(config)

Let's stop using JWTs client side

Sedky Abou-Shamalah — Tue, 08 Dec 2020 16:11:28 +0000

Here's an updated version of this blog:
https://sedkodes.com/blog/lets-stop-using-jwts

Split Token Flow: A solution to the security problem of the JWT

OAuth2, OIDC, and their foundation, the JWT, has been an industry standard for many years, with no sign of slowing down.

The problem with the JWT is the inherent leakiness. There is a massive debate amongst the community - where some consider JWT for auth as insecure as it leaks information (by b64 decoding the body), others argue that you shouldn't put sensitive info in there at all.

So that’s where the split token flow comes in. This flow suggests to use just the signature of the JWT access token on the client side, and storing the header and claims of the JWT server side. Thus, the split token flow satisfies both camps - we get the flexibility of JWTs by being able to store session information in JWT claims, and we get the security of an Opaque access token - because we don't actually expose the entire token, only the signature.

How can this be achieved with an API Gateway?

Full Disclosure, I am an employee of Tyk. The following guide contains screenshots of Tyk Pro product. However, all of this functionality is completely free to implement using the OSS Gateway as well. In fact, you can browse to this repository which will provide a step-by-step guide to doing the rest with the OSS Tyk Gateway.

First, let’s take an example of client credentials flow, where we exchange a client id and secret for a JWT access token that we can use to access our APIs:

$ curl -X POST -H 'Content-Type: application/x-www-form-urlencoded' https://keycloak-host/auth/realms/tyk/protocol/openid-connect/token \
-d grant_type=client_credentials \
-d client_id=efd952c8-df3a-4cf5-98e6-868133839433 \
-d client_secret=0ede3532-f042-4120-bece-225e55a4a2d6 \
> -s | jq
{
  "access_token": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyLCJlbWFpbCI6ImhlbGxvQHdvcmxkLmNvbSJ9.EwIaRgq4go4R2M2z7AADywZ2ToxG4gDMoG4SQ1X3GJ0",
  "expires_in": 300,
  "token_type": "bearer",
  "not-before-policy": 0,
  "scope": "email profile"

So here we get a JWT access token back:

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyLCJlbWFpbCI6ImhlbGxvQHdvcmxkLmNvbSJ9.EwIaRgq4go4R2M2z7AADywZ2ToxG4gDMoG4SQ1X3GJ0

Header

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9

Body

eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyLCJlbWFpbCI6ImhlbGxvQHdvcmxkLmNvbSJ9

Signature

EwIaRgq4go4R2M2z7AADywZ2ToxG4gDMoG4SQ1X3GJ0

We can plug that into jwt.io and see the decoded payload:

Clearly, the access token can contain sensitive information that we don’t want to leak.

The API Gateway is perfectly positioned to act as a broker between the client and the authorization server.

It can intercept requests from clients, receive a client id and secret, and exchange that for an access token with the authorization server. In this broker position, the API gateway can break apart the JWT, and return only the signature portion of the real JWT access token back to the client. We then store the rest of the JWT as metadata.

Setting it Up

Inside Tyk, let’s create a virtual endpoint or API, listening on the path "/auth/token".

Let’s take a look at some sample code for the Virtual Endpoint:

function login(request, session, config) {
    var credentials = request.Body.split("&")
        .map(function(item, index) {
            return item.split("=");
      }).reduce(function(p, c) {
             p[c[0]] = c[1];
             return p;
      }, {});

    var newRequest = {
      "Headers": {"Content-Type": "application/x-www-form-urlencoded"},
      "Method": "POST",
      "FormData": {
          grant_type: credentials.grant_type,
          client_id: credentials.client_id,
          client_secret: credentials.client_secret
      },
      "Domain": "https://keycloak-host",
      "resource": "/auth/realms/tyk/protocol/openid-connect/token",
    };

    var response = TykMakeHttpRequest(JSON.stringify(newRequest));
    var usableResponse = JSON.parse(response);

    if (usableResponse.Code !== 200) {
      return TykJsResponse({
        Body: usableResponse.Body,
        Code: usableResponse.Code
      }, session.meta_data)
    }

    var bodyObj = JSON.parse(usableResponse.Body);
    var accessTokenComplete = bodyObj.access_token;
    var signature = accessTokenComplete.split(".")[2];

    log("completeAccessToken: " + accessTokenComplete);

    // create key inside Tyk
    createKeyInsideTyk(signature, bodyObj)

    // override signature
    bodyObj.access_token = signature;
    delete bodyObj.refresh_expires_in;
    delete bodyObj.refresh_token;
    delete bodyObj.foo;

  var responseObject = {
    Body: JSON.stringify(bodyObj),
    Code: usableResponse.Code
  }
  return TykJsResponse(responseObject, session.meta_data)
}

function createKeyInsideTyk(customKey, meta) {
    // TODO: this needs to be a bit more dynamic. e.g. work out the policy id & API ID etc... based on the metadata
    var accessRights = {
        "c399587af48441d17bc5700339aa34fa": {
            "api_name": "Test API",
            "api_id": "c399587af48441d17bc5700339aa34fa",
            "versions": [
                "Default"
            ]
        }
    }

    log("meta: " + JSON.stringify(meta));

    var keyRequestBody = keyRequestTemplate;
    keyRequestBody.access_rights = accessRights;

    var newRequest = {
      "Headers": {"Content-Type": "application/json", "Authorization": "Bearer a4fcbde85a3c477d424922990eb16e01"},
      "Method": "POST",
      "Body": JSON.stringify(keyRequestBody),
      "Domain": "http://localhost:3000",
      "resource": "/api/keys/" + customKey,
    };

    var response = TykMakeHttpRequest(JSON.stringify(newRequest));
    log("createkeyintykres: " + response);
}

var keyRequestTemplate = {
    "apply_policies": [],
    "org_id" : "5d67b96d767e02015ea84a6f",
    "expires": 0,
    "allowance": 0,
    "per": 0,
    "quota_max": 0,
    "rate": 0,
    "access_rights": {}
}

The code does the following:

The Virtual Endpoint receives a request containing a client ID + Secret
It forwards the request to the authorization server and receives the access JWT token
It splits the access token, creating an opaque key in Tyk, which is the signature of the JWT access token
It adds the Header and the Body of the access token as metadata to that opaque key so that we can look it up on subsequent requests
It returns the opaque key (signature) to the client where they can use it to access APIs

At the beginning, from the client perspective:

$ curl http://tyk-gw:8080/auth/token -X POST -H 'Content-Type: application/x-www-form-urlencoded' -d client_id=efd952c8-df3a-4cf5-98e6-868133839433 -d client_secret=0ede3532-f042-4120-bece-225e55a4a2d6 -d grant_type=client_credentials

{"access_token":"MEwIaRgq4go4R2M2z7AADywZ2ToxG4gDMoG4SQ1X3GJ0","expires_in":300,"not-before-policy":0,"scope":"email profile","session_state":"fb8754d1-d518-40e8-a84f-85347a0639c8","token_type":"bearer"}

Let's look up the opaque token

And the key’s meta data

Let’s test our API key against the API we added to the access rights in the Create Key payload:

$ curl localhost:8080/basic-protected-api/get -H "Authorization: MEw….GJ0"
{
  "args": {},
  "headers": {
    "Accept": "*/*",
    "Accept-Encoding": "gzip",
    "Authorization": "MEwIaRgq4go4R2M2z7AADywZ2ToxG4gDMoG4SQ1X3GJ0",
    "Host": "httpbin",
    "User-Agent": "curl/7.64.1"
  },
  "origin": "192.168.80.1",
  "url": "http://httpbin/get"
}

Tyk validates the opaque token and allows access to the API.

In Tyk, let's reconstruct the full JWT and safely pass it to our upstream API.

In the previous step, we stored the full JWT in the session token’s metadata inside Tyk. We can extract the JWT from the request’s session metadata and then inject it into the requests headers.

Let’s configure the API to inject a global header like so:

Let’s try the API call again:

$ curl localhost:8080/basic-protected-api/get -H "Authorization: MEw….GJ0"
{
  "args": {},
  "headers": {
    "Accept": "*/*",
    "Accept-Encoding": "gzip",
    "Authorization": "Bearer eyJh...1X3GJ0",
    "Host": "httpbin",
    "User-Agent": "curl/7.64.1"
  },
  "origin": "192.168.80.1",
  "url": "http://httpbin/get"
}

Tada!
As you can see, even though we only sent an opaque token in the request, Tyk injected the rest of the JWT where our upstream can now use it to perform business logic.

If you have any questions or want to start a conversation, I encourage you to email me at sedky@tyk.io with any questions.

OSX Terminal Must Haves

Sedky Abou-Shamalah — Wed, 25 Nov 2020 03:20:05 +0000

Having a really efficient CMD line is awesome. It can save you a lot of time. It’s good to take the time to set up a terminal that is intuitive and customized to you and your workflow.

With the right software, you can do things like autocomplete your GIT commands, Docker commands and more. This alone is worth it. But also, you get DARK MODE!

Must Haves

iTerm2 — Replace and make this your default Terminal NOW. check out all the FEATURES!
Oh My Zsh — Steroids for your terminal. This gives us all the cool shit we need, like Autocomplete features, custom themes, and WAY MORE.
Go and install these two.

Docker/Git Auto complete

With iTerm2 and Oh My Zsh downloaded and installed, let’s add some plugins. Open your zsh profile, located in ~./.zshrc

edit the plugins section:

plugins=(
git
osx
docker
docker-compose
)
Now we get sweet autofill features. Here’s a list of hundreds of others:

such as minikube, node, and more!

Quick line jumps!

Are you a peasant that holds -> until they reach the end of the line? Well no more you aren’t!

You can setup iTerm2 to let you jump around the current line. Find the basics here to get you started:iTerm 2: How to set keyboard shortcuts to jump to beginning/end of line?I can see that Ctrl+ left/ right jumps to the beginning/end of line. How to change this to Cmd+ left/ right arrow? In…stackoverflow.com

Quick directory jumps!

A command line tool that helps you jump around to different directories using partial strings. Example:

Click here for the plugin link

If you have more, email me or comment ! Thanks!

Props to my buddy Rob Davis who shared these tips with me

Firebase SSO?

Sedky Abou-Shamalah — Wed, 25 Nov 2020 03:16:43 +0000

Edit: I've figured out how to implement this with a middle proxy layer, you can watch it on YouTube. I'm leaving the rest of the article unedited as it's still quite accurate.

If you're here because you are trying to figure out how to use Firebase for SSO purposes, let me be the first to tell you:

Firebase Authentication WAS NOT DESIGNED FOR SSO.

Turns out that a Federated IdP is not the same thing as an IdP. Who would’ve thunk it ?

HOWEVER. Can you build your own flows around it? Probably!

If you’ve worked with Firebase, you know it’s an amazing suite of products that allows you to rapidly prototype and build extremely scalable websites.

However, if you’re wondering if you can use Firebase Authentication for SSO, well, you can’t. Firebase Authentication is a federated IdP management system. It is the “client” in the OIDC/OAuth flow and for that reason, you can’t be a client in a client relationship.

There are tools that exist for this sort of thing, such as OneLogin, which are true SSO solutions. Firebase authentication is a good authentication tool for your websites, but it will not solve your SSO problems outside of that.

Interestingly enough, you can bypass Firebase and then use one of the underlying IdPs to SSO into platforms. For example, instead of using Google Login through Firebase, you could just use Google Login. Same with Facebook Login. These are true IdP solutions which implement OIDC and OAuth2 frameworks correctly. But when Firebase is in the middle, you cannot use them except to log into a web app you are building.